rust: persist toolchain inside env (fixes #3678)#3684
Conversation
- Move RUSTUP_HOME inside envdir so the toolchain installed by
`rustup toolchain install` survives the function return
(was a TemporaryDirectory that got rm-rf'd).
- Set RUSTUP_HOME + RUSTUP_TOOLCHAIN in `get_env_patch` so both
install and hook-run see the env-local toolchain.
- Pin `--profile default` so rustfmt/clippy ship with the toolchain
regardless of the user's `rustup set profile` config.
- Scope `CARGO_HOME=envdir` to the rustup-init bootstrap only, so
hooks still see `~/.cargo/{config,credentials}.toml`.
- Add a `health_check` to invalidate envs built by the old layout
and envs whose installed toolchain no longer matches the configured
`language_version`.
Fixes pre-commit#3678
|
sorry we don't accept ai slop PRs |
|
What is your metric for AI slop exactly? |
|
well for starters I don't think you understand what the llm changed and this doesn't even do the minimal work to fix the "problem" (if there even is one -- the original issue never really triaged as to whether something wasn't working or not) |
sets RUSTUP_HOME as a temp dir that gets deleted when exiting the context manager. Installs the toolchain into RUSTUP_HOME So when the function is exited, RUSTUP_HOME gets deleted. You still have your proxies in CARGO_HOME/bin, so you can still pick up a version of rust sometimes (and this whole path is only triggeredfor npn-system rust environments, which is rare) so this is normally not caught. What my PR does is simply decouple RUSTUP_HOME, set by and the temporary dir, which is now only used to download rustup The rest of the changes (basically just checkhealth) were to make sure I did not affect current users of pre-commit by mistake. If pre-commit thinks that an old env already exists, it double checks the structure of the directories to not have the broken toolchain. Now, seeing the number of closed PRs, I appreciate that being a maintainer you must get a load of slop PRs, so let me know if you would prefer this PR to be smaller (i.e. fewer test changes or getting rid of the checkhealth and having that as a separate PR), but this is a real bug and I'm just trying to upstream the fix. Otherwise, I can also just not upstream this amd just patch to fix #3678, but that's a bug we are getting and I'm just trying to help |
When pre-commit bootstraps Rust itself, the previous code installed the toolchain into a
TemporaryDirectorythat was deleted as soon asinstall_rust_with_toolchainreturned. At hook-run time, the rustup proxy could then silently auto-install the requested toolchain into the user's~/.rustupusing their globally configured profile. On CI images that setrustup set profile minimal, this could droprustfmtandclippyand break those hooks.This PR keeps the Rust toolchain env-local instead.
Changes:
RUSTUP_HOME=envdir/rustupandRUSTUP_TOOLCHAIN=<version>inget_env_patch, so the installed toolchain persists and is found at both install and hook-run time.rustupintoenvdir/bin/whenever it's missing there, regardless of system rustup, so the env stays self-contained even if the user uninstalls system rustup later.CARGO_HOME=envdirto therustup-initbootstrap call only, so cargo still reads the user's~/.cargo/{config,credentials}.tomland shared registry cache during normal use.--profile defaultsorustfmtandclippyship with the toolchain regardless of the user's globally set rustup profile.health_checkthat rebuilds envs built by the previous layout, and envs whose installed toolchain no longer matches the configuredlanguage_version.install_rust_with_toolchain('system', ...)withValueErrorso the helper can't silently degrade to PATH-only env patching.Tests cover:
get_env_patchshape for system, default, and pinned versionsrustup-initandrustup toolchain install --profile defaultCARGO_HOMEscoping torustup-initonlyrustfmtthrough pre-commit