Seeking beta testers for Rustup v1.28.0

community
1

Hi everyone!

I'd like to announce on behalf of the rustup team that rustup 1.28.0 beta is now available for testing and we are currently looking for beta testers.

The following improvements might require changes to how you use rustup:

  • rustup will no longer automatically install the active toolchain if it is not installed. pr#3985

    • To ensure its installation, run rustup toolchain install with no arguments.
    • To help with the migration, the following command installs the active toolchain both before and after this change:
      rustup show active-toolchain || rustup toolchain install
# Or, on older versions of PowerShell:
rustup show active-toolchain; if ($LASTEXITCODE -ne 0) { rustup toolchain install }

  • Installing a host-incompatible toolchain via rustup toolchain install or rustup default will now be rejected unless you explicitly add the --force-non-host flag. pr#4028

As usual, we would be happy to receive regression/breakage reports of any kind, especially regarding the installation/usage on the following platforms/environments:

  • Toolchain downloads: Rustup has migrated to reqwest with rustls as the default download backend and rustls-platform-verifier as the server certificate verifier on supported platforms. Please let us know if you have any issues in this respect.
    • If issues do happen, RUSTUP_USE_CURL and RUSTUP_USE_RUSTLS can still be used to manually change the download backend.
  • nu shell: This version should automatically handle PATH configs for your rustup installation, but if you have already installed rustup on your machine, a reinstallation might be required to make the config work out of the box.
  • aarch64-pc-windows-msvc and loongarch64-unknown-linux-musl: This will be the first release to support these host platforms.
    • Additionally, you will be able to use https://win.rustup.rs/aarch64 to download the prebuilt installer for aarch64-pc-windows-msvc. Please note that this link still leads you to the v1.27.1 release today, but it will be up to date once this release becomes stable.
  • The new output format: The output format of certain commands such as rustup show has been updated to make it easier to find the active toolchain. However, this might break your application if you are launching rustup as a subprocess and parsing its output. If that happens, please let us know!
  • The new homepage: A preview of our new project homepage is located at https://dev.rustup.rs. Please feel free to have a look!

To begin testing this new version, all you need to do is simply switching to the dev environment by setting the RUSTUP_UPDATE_ROOT=https://dev-static.rust-lang.org/rustup environment variable and update (or install) rustup. [1]

Finally, please don't forget to check out the corresponding section in our CHANGELOG.md for the complete list of changes included in this version.

Many thanks in advance, and happy holidays :four_leaf_clover:

  1. To switch out of the dev environment, just remove that environment variable and do a rustup self update. ↩︎

12 Likes
2

I assume this is for persisting $env.PATH updates for nushell on a unix machine? I primarily use nushell on Windows, but at least I personally would still expect for rustup to edit the user registry %PATH% instead of adding an overlay just for nushell.

Alternatively it may be about updating $env.PATH after initial installation, without needing to reload the shell. That would be a nice-to-have, although I've set my config up to constantly reapply the registry path[1].

  1. IIRC, I have it set up to append PATH from the registry and then deduplicate, meaning I can't ever remove a registry PATH entry from a session, but any session PATH additions will be prioritized over new entries from the registry. ↩︎

1 Like
3

You are right! To be clear, this is indeed about persisting $PATH on Unix since that has to be configured on a per-shell basis.

When it comes to Windows I believe the behavior stays the same (it modifies the global $env.PATH in the registry), and we already have prompted the user to reload the shell on Windows so the installation should be fine in that case.

1 Like
4

I think I've found one behavior change, which may potentially break custom channel manifest TOML: Since Use serde to encode/decode various TOML formats by djc · Pull Request #3864 · rust-lang/rustup · GitHub, rustup has switched to serde from the manual TOML validation. The parsing logic differs in some situations like having a [pkg.rust-mingw] table containing zero [pkg.rust-mingw.target] table in it. That would result in a error like

error parsing manifest: TOML parse error at line xxx, column y
    |
xxx | [pkg.rust-mingw]
    | ^^^^^^^^^^^^^^^^
missing field `target`

I wrote a cargo script to check Rust toolchains from 1.8.0 (v2 starts from this) to 1.83.0. All manifests are valid and happy with the new rustup manifest parser.

verify-all-manifests.rs

---
[package]
edition = "2024"
[dependencies]
rustup = { git = "https://github.com/rust-lang/rustup", rev = "ae210ce38e667ee542813465934ec42d7b7b692e" }
---

use std::path::Path;

use rustup::dist::manifest::Manifest;
use rustup::utils::read_file;

fn main() {
    let manifest_path = std::env::args_os().skip(1).next().expect("requires a path to manifest file");
    let manifest_path = Path::new(&manifest_path);
    let manifest = read_file("manifest", manifest_path).unwrap();
    match Manifest::parse(&manifest) {
        Ok(_) => eprintln!("... ✅ {}", manifest_path.display()),
        Err(e) => eprintln!("... ❌ {}: {e}", manifest_path.display()),
    }
}

verify-all-manifests.bash

#!/usr/bin/env bash

cargo +nightly -Zscript build --manifest-path ./verify-all-manifests.rs

mkdir tmp

# we have manifest v2 since 1.8.0
for i in $(seq 8 83);
do
    name="channel-rust-1.${i}.0.toml"
    dst="tmp/${name}"
    if [ ! -f "${dst}" ]; then
        curl -L "https://static.rust-lang.org/dist/${name}" > "${dst}"
    fi
    cargo +nightly -Zscript --quiet ./verify-all-manifests.rs "${dst}"
done

I don't think there is a real use case of a pkg table without any valid targets. And since none of the official manifest file is affected, I don't think we need to take any action. Left this comment here just for prosperity.

5

The migration script doesn't really work if there is no default toolchain. See `rustup show active-toolchain` exits 0 when no default and no active toolchain · Issue #4140 · rust-lang/rustup · GitHub

6

Without a default toolchain configured, rustup default exits with non-zero in 1.27.1, but with zero in 1.28-beta. Is that also worth a incompatibility note?

1 Like
7

Thanks for the report! It's definitely a bug on our side; will fix.