rust-lang / rust-lang/rustup

Expressing "any stable" or "any nightly" in `+` expressions

Open
#3,015 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Rust
Stars
7k
Forks
1.1k
Avg merge
22h 40m
Merged PRs (30d)
46

Description

Problem you are trying to solve

I'd like a build script to work in different environments, both CI contains and various user setups. In the CI container, there is usually a pinned nightly version installed, but many users just have the latest around (and that's OK -- breakage in the used features is rare, and when it occurs, we'd rather know soon and not when we urgently need the nightly bumped for other reasons).

This all works well as long as I can assert that the installed nightly is the default toolchain -- but in user environments I can't easily do that. To accommodate the widest variety of user setups, I'd like to invoke cargo in such a way that it picks either nightly, or (if a toolchain literally called "nightly" is not installed) the latest installed one.

(Same goes for stable, really, but stable is really so stable that old versions are rarely around, and also our CI is not pinned to a particular stable version but trusts Rust's stability; it probably makes sense to address these in parallel, but for stable it doesn't affect me yet).

Solution you'd like

I see various options for solving this, some aligned with existing issues (but none perfectly):

  • https://github.com/rust-lang/rustup/pull/2596 looks like it's on the path to makeing the desired behavior the default. It'd only work for a limited number of cases (+nightly only selects nightly-2022-03-08 if there is exactly one versioned nightly, plus it wouldn't work for stable/1.xx), but it'd solve the pressing issue.
  • https://github.com/rust-lang/rustup/issues/555 would not do the right thing as it is written -- but it would if it is extended to symmetry (rustup run stable runs 1.9.0 if that is installed and happens to be the current stable), and if no attempts are made to determine whether that label is still current (after all, it was current at least at some point in the past).
  • Toolchain aliases. This is suggested in https://github.com/rust-lang/rustup/issues/1556, and going that route would require installing things like rustup toolchain add nightly=nightly-2022-03-08 in the CI containers.
    That'd be fine with me, but I'm not sure what the semantics are of overriding a name with a channel.
  • cd ~/.rustup/toolchains; ln -s nightly-2022-03-08-x86_64-unknown-linux-gnu nightly-x86_64-unknown-linux-gnu works surprisingly well, but I'd be worried that this breaks things inside rustup. (Then again, that trick would only be used inside the CI container that never does a rustup update ... maybe it's good enough, maybe some users tries to update Rust because they use the container for more, and then things fall apart).
  • https://github.com/rust-lang/rustup/issues/1974 would not directly solve this, but it might share internals.
  • The current workaround is +$(rustup toolchain list | sed 's/ .*//' |grep nightly | tail -n1) -- but that feels very crude.
Notes

I don't see much of a compatibility hazard in using "any nightly" that way -- after all, if the build script just said cargo +nightly it'd also rely on some pre-agreement that the installed nightly is "recent enough". If only an old explicitly versioned nightly is around, the user could just as well have installed "nightly" back when that was recent, so no new dangers come up by falling back to "the latest nightly-*" compared to just saying "nightly".

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the toolchain resolution behind cargo +nightly, rustup run stable, and rustup toolchain list; the issue names no source files or tests. Review the linked issues and determine the intended semantics for falling back from an uninstalled channel to the latest installed versioned channel. Done means the behavior is specified, implemented, and covered for both stable and nightly cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.