-
Notifications
You must be signed in to change notification settings - Fork 893
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
Update on install #2339
Update on install #2339
Conversation
So I think always prompting about this is a mistake, since all users will have to care about this. We should either:
I'd prefer the former UX since then there's only one block of prompts. |
I've commented on #2330 - I don't think prompting is ever desirable here. |
29ef83e
to
c6caad9
Compare
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
c6caad9
to
b02bc1a
Compare
@Manishearth How do you feel about this prototype? |
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.
If i'm reading this right this unconditionally does the equivalent of rustup update <default>
on install unless otherwise specified?
Seems good to me!
Yep that's the intent. Okay, @rbtcollins how about you? Are you okay with this? |
I'm sorry, I don't know how to test this. I'm sure y'all know what's right for your project tho. This said, I don't understand why you're trying so hard to avoid a prompt given when last I ran it, rustup.sh already shows a prompt? |
@mcclure the initial prototype prompted for every install, even if there wasn't an existing installation to update, which means a lot of people need to go through an unnecessary prompt. The current prototype never prompts, which is also fine IMO, it's hard to see a use case for not updating an existing install when you are installing rustup (as opposed to updating it) |
@@ -81,6 +81,11 @@ pub fn main() -> Result<utils::ExitCode> { | |||
.multiple(true) | |||
.use_delimiter(true), | |||
) | |||
.arg( | |||
Arg::with_name("no-update-default-toolchain") |
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 feel this is a bit verbose. We have --no-self-update; perhaps just --no-update ?
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 will have a ponder. --no-update
feels a little odd but the terseness may be okay. I'll reconsider in the face of the rest of the args, it is a bit long yes.
@@ -14,6 +14,12 @@ use std::io::Write; | |||
use std::process::Stdio; | |||
use std::sync::Mutex; | |||
|
|||
macro_rules! for_host { |
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 really feel that a used-once macro that just forms a function once, used in a single test is really pulling its weight - but if you feel it is going to be used again I'm cool with it being added.
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'm intending, once this is merged, to file an e-easy e-mentor help-wanted to move those macros into mock/clitools.rs
This is a semi-prototype, but in theory ready-for-showtime attempt at resolving #2330
Opinions from @Manishearth and @mcclure are invited.