Skip to content

Command for "install stuff from rust-toolchain.toml" #2686

Description

@jmaargh

Apologies if this already exists, but I couldn't find it in the docs or shell help. Or if there is an alternate workflow for this.

I love rust-toolchain.toml, it's a great idea. It would be even more useful if there were a command such as rustup override install, which would look at the current rust-toolchain.toml and install the toolchain and components specified there. It would be super useful both when exploring projects for the first time, but also when using disposable container-based development environments.

I'm unopinionated on the exact syntax of this command. Also happy to help implement this if the maintainers want it.

### Tasks
- [ ] https://github.com/rust-lang/rustup/issues/3972

Activity

  1. rbtcollins commented on Mar 2, 2021

    @rbtcollins
    Contributor

    See #1397

  2. jmaargh commented on Mar 2, 2021

    @jmaargh
    Author

    I feel like there's value in keeping this issue different from #1397 for a couple of reasons:

    1. The main point of rustup show should not force-install the default toolchain if it is not installed. #1397 is to disable a certain behaviour, this is to add that behaviour somewhere else (something that was discussed in rustup show should not force-install the default toolchain if it is not installed. #1397, but isn't the main point)

    2. It's not clear to me from rustup show should not force-install the default toolchain if it is not installed. #1397 whether what's being discussed is installing just the toolchain per-se, or also the components that can be set in a rust-toolchain.toml file. This issue is suggesting ensuring that everything specified in rust-toolchain.toml is installed and available.

  3. kinnison commented on Mar 11, 2021

    @kinnison
    Contributor

    I think that ensuring rust-toolchain{,.toml} is properly honoured is an all-or-nothing thing - it couldn't "just" be the toolchain itself, no matter what.

    You're right that #1397 is about ensuring that we don't over-indulge in autoinstallation, and I think this is a good home for how we then permit manual triggering of what was previously automatic.

    I continue to think something like rustup toolchain ensure [PATH] seems like a good approach, but further straw men for discussion would be good.

  4. jmaargh commented on Mar 12, 2021

    @jmaargh
    Author

    I'm easy about the syntax. rustup toolchain ensure [path] works for me.

    I was thinking re-using rustup toolchain install, so:

    • rustup toolchain install [toolchain] works as currently
    • rustup toolchain install [path to rust-toolchain.toml] installs according to the specified file
    • rustup toolchian install [path to directory] finds the rust-toolchain.toml that would apply to that directory (if any) and asks for confirmation before installing, with the confirmation prompt specifying exactly which file and that you could have specified a toolchain instead.
    • rustup toolchain install acts as rustup toolchian install .
  5. kinnison commented on Mar 12, 2021

    @kinnison
    Contributor

    Given all the other arguments rustup toolchain install can be given, I'd favour a separate verb.

  6. rbtcollins commented on May 4, 2021

    @rbtcollins
    Contributor

    There's a request to permit this during rustup-init as well; I've marked them as dup because I think its basically the same work... getting to a oneline for rustup not being installed is doable via:
    rustup-init -y --no-update-default-toolchain && rustup toolchain ensure . (or whatever design we end up settling on).

  7. added this to the 1.25.0 milestone on Jun 8, 2021
  8. eminence commented on Mar 30, 2022

    @eminence

    I'd also like to have rustup-init be able to read a rust-toolchain file to figure out what toolchain to install. In my specific use case, I'm install rust (via rustup-init) as part of my CI scripts. Currently I'm using:

    rustup-init.exe --no-modify-path --default-toolchain stable --profile minimal -y
    

    Since my rust-toolchain file lists channel = "1.59", rustup will end up installing the stable channel (during initial install), and then later installing 1.59 (during the build).

    I could resolve this by manually keeping my CI scripts in-sync with my rust-toolchain file, but I'd prefer to just manage rust-toolchain. (Another possible solution to my problem might to have something like --profile empty as suggested in #2970. This would let rustup-init do some very minimal work and let the normal toolchain file mechanisms do the right stuff)

  9. rbtcollins commented on Mar 30, 2022

    @rbtcollins
    Contributor

    @eminence just use --default-toolchain none then ?

  10. eminence commented on Mar 30, 2022

    @eminence

    Ah, sorry, I didn't know that was possible! I didn't see it listed in --help, It'll give it a try!

  11. jmaargh commented on Mar 31, 2022

    @jmaargh
    Author

    Given someone has actually started trying to implement this functionality, should we agree on syntax?

    Based on the above, people seem to be keen for a new verb and have been using ensure (and I'm not able to think of one I prefer right now), so let's move ahead with that and not bikeshed (it can easily be changed last minute if needed).

    As for exact syntax, based on my suggestion above I'd suggest:

    • rustup toolchain ensure [path to rust-toolchain.toml] installs according to the specified file
    • rustup toolchian ensure [path to directory] finds the rust-toolchain.toml that would apply to that directory (if any) and asks for confirmation before installing, with the confirmation prompt specifying exactly which file it's found.
    • rustup toolchain ensure acts as rustup toolchian ensure .

    I'd also suggest a confirmation prompt by default, listing the path to the file it's using and what it's about to install, with a -y|--yes flag to skip the confirmation. Not a strong opinion on this one, if people don't like the confirmation then just do without.

    Are people happy with this? Anything we want to change?

  12. lopopolo commented on Mar 31, 2022

    @lopopolo
    • rustup toolchain ensure [path to rust-toolchain.toml] installs according to the specified file

    I want to chime in with a big yes for this. One reason I've been holding off on moving from the legacy rust-toolchain file to rust-toolchain.toml is because I rarely want CI to install all of the components that are nice to work by default in local development scenarios.

    If I could stash a CI-specific toolchain file in .github/rust-toolchain-clippy.toml or similar, I'd be able to rustup toolchain ensure .github/rust-toolchain-clippy.toml, that would let me use the new format and still use more minimal toolchain files in CI environments.

    On a similar note, some of my projects use e.g. nightly rustdoc for building crate docs or nightly rustfmt which I invoke like:

    rustup run --install nightly cargo doc --workspace
    rustup run --install nightly cargo fmt -- --color=auto
    

    Unfortunately this invocation doesn't let me specify components to install on the nightly toolchain and makes it more difficult to onboard new contributors to local development.

    Is something like rustup toolchain ensure path/to/toolchain.toml run ... something we can consider here too?

  13. 5 remaining items

  14. djc commented on Nov 20, 2023

    @djc
    Contributor

    @jmaargh I think adding an ensure command like that would make sense, yes.

  15. jmaargh commented on Nov 20, 2023

    @jmaargh
    Author

    @djc Are you a maintainer? I don't want to start working until maintainers have agreed in principle.

  16. rami3l commented on Nov 21, 2023

    @rami3l
    Member

    @djc Are you a maintainer? I don't want to start working until maintainers have agreed in principle.

    Yes (and so am I). Please go ahead with it! 🙏

  17. modified the milestones: 1.25.0, 1.28.0 on Jan 17, 2024
  18. self-assigned this
    on Aug 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions