[Bug]: rustup always overwrites CARGO_HOME

[marknefedov]

Prerequisites

• [X] I have written a descriptive issue title.
• [X] I have searched all issues/PRs to ensure it has not already been reported or fixed.
• [X] I have verified that I am using the latest version of Scoop and corresponding bucket.

Package Name

rustup

Expected/Current Behaviour

With the introduction of Windows Dev Drive, I want to move cargo folder as per Microsoft recommendation. Scoop install always overrides CARGO_HOME, so I can't change folder to custom location.

Steps to Reproduce

setx CARGO_GOME E:/packages/cargo
scoop install rustup
echo $env:CARGO_HOME # This results in C:\Users\user\scoop\persist\rustup\.cargo

Possible Solution

Do not overwrite environment variable https://github.com/ScoopInstaller/Main/blob/727f1212dc401ee658f1a313ccbd7974370673f9/bucket/rustup.json#L33-L35 Pass existing environment variables https://github.com/ScoopInstaller/Main/blob/727f1212dc401ee658f1a313ccbd7974370673f9/bucket/rustup.json#L26-L29

Scoop and Buckets Version

Current Scoop version:
v0.3.1 - Released at 2022-11-15

'extras' bucket:
989df8fb9 (HEAD -> master, origin/master, origin/HEAD) steamcmd: Update to version 1691628584

'java' bucket:
2e9a6179 (HEAD -> master, origin/master, origin/HEAD) temurin11-nightly-jre: Update to version 11.0.21-1.0.202308081844

'main' bucket:
727f1212d (HEAD -> master, origin/master, origin/HEAD) red: Update to version 10aug23

'versions' bucket:
6db6c0f9a (HEAD -> master, origin/master, origin/HEAD) vlc-nightly: Update to version 20230810

Scoop Config

scoop config

last_update         scoop_branch scoop_repo
-----------         ------------ ----------
10/08/2023 10:17:13 master       https://github.com/ScoopInstaller/Scoop

PowerShell Version

$PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.3.6
PSEdition                      Core
GitCommitId                    7.3.6
OS                             Microsoft Windows 10.0.22631
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Additional Softwares

No response

[HUMORCE]

For special use cases, you should create custom manifest instead of changing the general solution.

This report are similar to https://github.com/ScoopInstaller/Main/issues/5006

[rashil2000]

I think including a check for the existence of those variables is an acceptable solution.

[HUMORCE]

I think including a check for the existence of those variables is an acceptable solution.

I don't think it's acceptable, when the manifest explicitly states that environment variables will be changed/added/seted:

❯ scoop info rustup

Name        : rustup
...
Environment : CARGO_HOME = <root>\.cargo
              RUSTUP_HOME = <root>\.rustup
Path Added  : <root>\.cargo\bin

---

For users who run scoop install rustup when they already have a rustup installation, we should assume that them wanting a rustup(Scooped).

Compared to package manager under *nix, Scoop does not (re)build program from source, then: https://github.com/ScoopInstaller/Main/issues/5006#issuecomment-1669231783

We just missing docs for these issue:

Scoop should follow Principle Of Least Surprise and stick to upstream defaults unless there is a good justification for doing so and in which case it must be documented.

https://github.com/ScoopInstaller/Main/issues/5006

[hagaigold]

For special use cases, you should create custom manifest instead of changing the general solution.

Another option: adding to config.json a customized "env_set" section, that will be loaded after each update/install.
I think it is easier to maintain than a custom manifest.

[rashil2000]

I think including a check for the existence of those variables is an acceptable solution.

The thing is, there's already a precedent for this: see https://github.com/ScoopInstaller/Main/issues/4512

@niheaven what do you think?

[niheaven]

Prefer a customized manifest here, but yes, I know the benefit of Dev Drive, and may give a config option to overwrite the default behavior of envvar creation.