-
Notifications
You must be signed in to change notification settings - Fork 459
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add progress bar to install command #1028
Conversation
🦋 Changeset detectedLatest commit: 065ff49 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
} | ||
} | ||
|
||
impl Drop for ResponseProgress { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using Drop because the XzDecoder takes ownership of the reader. Ensures the progress bar is finalized once the download is completed. Not sure if there's a better way of doing this.
src/progress.rs
Outdated
bar.set_style( | ||
ProgressStyle::default_bar() | ||
.template("[{elapsed_precise}] [{bar:40}] {bytes}/{total_bytes} ({bytes_per_sec}, {eta})") | ||
.unwrap() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can return a TemplateError
from indicatif when the template has a syntax issue. Unwrapping because it's a static template.
|
||
/// Do not display a progress bar | ||
#[clap(long)] | ||
pub no_progress: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think clap has a way to add --progress/--no-progress
to enable or disable a flag, just made a progress bar the default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fyi, I'm gonna change that before releasing to --progress=never
, and will have --progress=auto|always
so auto
will be based on the log level
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a future PR it would be cool to add the extraction into account too, so we have a multi progress bar if necessary to show download+extraction which are both tasks that stream and take time 😌
src/downloader.rs
Outdated
path: P, | ||
response: crate::http::Response, | ||
) -> Result<(), Error> { | ||
fn extract_archive_into<P: AsRef<Path>, R: Read>(path: P, response: R) -> Result<(), Error> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a thought (not important, can be done in a different PR): what do you think about starting to use impl
instead of generic constraints? seems more readable right?
fn extract_archive_into<P: AsRef<Path>, R: Read>(path: P, response: R) -> Result<(), Error> { | |
fn extract_archive_into(path: impl AsRef<Path>, response: impl Read) -> Result<(), Error> { |
is there a way to test a progress bar? |
bar | ||
} | ||
|
||
impl ResponseProgress { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you think we should unit test this somehow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a test to ensure we still read from the underlying response with the progress wrapper. Also added a indicatif::TermLike
impl that captures the progress bar activity and saves all the activity into a String, then checks for "#" characters in the string after reading all the data.
The mock impl is a bit verbose so I added it in a separate commit to revert it easily. Let me know if you'd prefer to just test the read operations pass through.
Ensures data is still read from the request. indicatif does not expose their Term struct, so it is difficult to mock a terminal to verify the progress bar looks correct.
Looks like there are some failing e2e tests, saying "operation timed out" when trying to hit the proxy. Any ideas what's going on there? Some kind of rate limiting from the nodejs servers? |
I'll merge this and add some fixes, thank you so much for this contribution and sorry I haven't merged it till now |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This adds the feature requested in #949. Doesn't display if the response from the download mirror doesn't have a content-length header.
I hard-coded a bar template, looks like this:
I think we could add an env var to customize this, but we'd need to handle syntax errors gracefully (show warning, maybe?).
Added a
--no-progress
option to turn this off. It writes to stderr.