-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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 a term option to configure the progress bar #8165
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Eh2406 (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
☔ The latest upstream changes (presumably #8167) made this pull request unmergeable. Please resolve the merge conflicts. |
Thanks for the PR! Can you say a little more about your use case? It seems like it would be preferable, if you want to display a GUI progress bar, to use JSON instead of trying to parse the text. If Cargo provided whatever information is needed in JSON to compute a progress bar, would that work better for you? A while back, I worked on a similar feature for controlling the progress bar, though I put it in config (here is the unfinished work). I ultimately decided it was a little too weird, but it would be possible to go that route. Generally it would be a config like: [term]
progress = { when = 'always', width = 100 } With it being a config value, it gets environment variable support for free. It also provides a way to pass in the width (hard-coding to 80 seems a little uneasy). We've also had a few requests for the ability to turn it off, but keep colored output, which this would also support. |
@ehuss Hi!
I use the progress bar not only to display a GUI progress bar, but also to understand when to finish build events in the event tree. For example:
This is how it looks for projects with many dependencies: NB: The progress bar is necessary to build the event tree, so I need it to always be shown. For now, I use a terminal emulator and remove the Also, I don't want to limit the maximum line length because I need parse all crate names.
Yes, it would be perfect. The JSON message can include more information, for example, crate versions ( |
If JSON messages would work better, would you be willing to work through and suggest what needs to be added? The Are there any other messages that would be required? |
@ehuss, sorry for a long response. It looks like the
fn main() { 0 } Result:
I use the following cargo messages:
So at least I need start message and finish message with build status (fresh, success, failure, skipped) for every unit.
Yes, this and start/finish messages should be enough to render the GUI progress bar.
It would be nice if start/finish messages contain information about which package this unit belongs to. Thus, we can create a separate subtree for units with the same package. Also, cargo doesn't apply the
So I have to parse lines with |
Thanks for the details! So it sounds like there are at least 2 new messages to add?
I'm uncertain about the best way to express "progress". There are different stages (updating indexes, resolving, downloading, compiling, etc.). Using "unit count" may not be the best option due to that, and also that could make it difficult in the future if Cargo is more lazy or dynamic when deciding what to build (although maybe the unit count could be documented as an "estimate"?). An option is to have an initial "build-started" JSON message with the estimated unit count? An alternative is to have Cargo compute some estimated progress amount as a number from 0 to 1. It could then include that in the JSON messages (or maybe as a separate message). I'm also wondering about whether to show progress for the downloading phase separately, or should it just be part of a single "progress" progression? Downloading can be quite slow. I wonder, do any other build tools have a similar concept?
I filed #8283 for this. It is something I've wanted for a long time. |
☔ The latest upstream changes (presumably #8287) made this pull request unmergeable. Please resolve the merge conflicts. |
I think it would be useful to go ahead and add a config option. However, as mentioned above at #8165 (comment), I would kinda prefer the schema described there. I don't remember the exact status of the linked patch, but just a quick look it seems complete. If you want to try to rebase it and see if it works, that would be helpful. And if there are any questions, just let me know. |
@ehuss This is not suitable for my case, because I need to run cargo with progress bar regardless of the settings specified by the user, i.e. I need a way to override user's settings from the IDE side. It can be a command-line option or an environment variable. I have found recently added |
Maybe I'm a bit confused, but all config options can be set with environment variables. In this case, it would be |
Oh, I didn't know it. Now I understand what you meant when you said, "it gets environment variable support for free" :) I have rebased your patch, but it looks like this line from failed to parse p.s. It correctly parses |
☔ The latest upstream changes (presumably #8629) made this pull request unmergeable. Please resolve the merge conflicts. |
If you mean it doesn't work with environment variables, I think the following should fix it: diff --git a/src/cargo/util/config/mod.rs b/src/cargo/util/config/mod.rs
index c50ee8771..6cc34a3cc 100644
--- a/src/cargo/util/config/mod.rs
+++ b/src/cargo/util/config/mod.rs
@@ -1852,7 +1852,7 @@ where
}
}
- deserializer.deserialize_any(ProgressVisitor)
+ deserializer.deserialize_option(ProgressVisitor)
}
/// A type to deserialize a list of strings from a toml file. |
@ehuss I have added some tests, but, for some reason, |
Ah, I think the change to deserialize_option makes it go through a different code path. I believe the diff --git a/src/cargo/util/config/mod.rs b/src/cargo/util/config/mod.rs
index b75a86e31..eda4daade 100644
--- a/src/cargo/util/config/mod.rs
+++ b/src/cargo/util/config/mod.rs
@@ -1862,14 +1862,7 @@ where
where
D: serde::de::Deserializer<'de>,
{
- ProgressConfig::deserialize(deserializer).map(Some)
- }
-
- fn visit_map<M>(self, map: M) -> Result<Self::Value, M::Error>
- where
- M: serde::de::MapAccess<'de>,
- {
- let pc = Deserialize::deserialize(serde::de::value::MapAccessDeserializer::new(map))?;
+ let pc = ProgressConfig::deserialize(deserializer)?;
if let ProgressConfig {
when: ProgressWhen::Always,
width: None, |
@ehuss Thanks! Now the PR is ready. |
Thanks, can you also update the documentation? The places that need updating:
|
@ehuss Done. |
@rfcbot fcp merge @rust-lang/cargo This adds a new, stable configuration option. I feel like it is minor enough that it does not need to go through the unstable process, though feel free to disagree. The option is
|
Team member @ehuss has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
Thanks! |
📌 Commit d649c66 has been approved by |
☀️ Test successful - checks-actions |
Update cargo 7 commits in 8777a6b1e8834899f51b7e09cc9b8d85b2417110..05c611ae3c4255b7a2bcf4fcfa65b20286a07839 2020-09-15 19:11:03 +0000 to 2020-09-23 23:10:38 +0000 - --workspace flag for locate-project to find the workspace root (rust-lang/cargo#8712) - Remove some badges documentation. (rust-lang/cargo#8727) - Add plain message format for locate-project (rust-lang/cargo#8707) - Add a term option to configure the progress bar (rust-lang/cargo#8165) - Replace d_as_f64 with as_secs_f64 (rust-lang/cargo#8721) - Add cross check to filters_target test. (rust-lang/cargo#8713) - Add test for whitespace behavior in env flags. (rust-lang/cargo#8706)
Closes #7587.