rustup is not creating $HOME/.cargo/env

Created on 27 Nov 2020  路  14Comments  路  Source: rust-lang/rustup

I don't want $HOME/.cargo/env being sourced in my $HOME/.profile or my $HOME/.bashrc.
Still, it is convenient to have $HOME/.cargo/env generated since I will source this file anyway under certain circumstances.

However, $HOME/.cargo/env is not created when I perform the installation as shown below

$ curl https://sh.rustup.rs -sSf | sh -s -- --no-modify-path -y

Bug or feature?

Thanks a lot,

bug

Most helpful comment

I think I agree that it's a bug we're not writing the env file out on --no-modify-path - I'm working on a test (and from there a fix) right now.

All 14 comments

Further to discussion on Discord, we think this might be failing to create the env file if it detects the presence of the sourcing lines in the RC files. @workingjubilee ?

Indeed. I confirm that if the sourcing instructions are already present on the RC files, the command below does not create the env file:

$ curl https://sh.rustup.rs -sSf | sh -s -- -y

That is probably what is happening! I did not anticipate this use case. I will submit a patch.

@frgomes I don't need to know, but I would be most interested to hear what the "certain circumstances" are, to better understand this sort of desire in general in the future.

(copying from Discord)

I employ multiple virtual environments for multiple distinct activities.
https://www.pythonforbeginners.com/basics/how-to-use-python-virtualenv
The link above looks more complicated than it really is: in the end it is just something like "source a shell script containing definitions for environment variables and modifications to PATH only when I need those definitions and modifications", which avoids having a PATH containing 50 entries when I need only 4 or 5 when developing on a certain version of a certain programming language. In the case of Rust, I will be sourcing $HOME/.cargo/env only when I need Rust visible as a development tool. Nothing special, really.

I fully second this! In my case the issue I have is that in some continuous integration system, the .bashrc file is not writable by rustup because of some permission reasons so I need to rely on --no-modify-path but at the same time I want to manually call source $HOME/.cargo/env later on.

On a side note, when rustup is not creating the $HOME/.cargo/env file, it still shows the following message:

    To configure your current shell, run:
    source $HOME/.cargo/env

which is kind of confusing since the file does not exist.

This broke my CI in exactly the same way as it did for @marmeladema. Is there a plan to roll out a fix quickly? If not, I'll adjust my CI to add the PATH by hand.

I think I agree that it's a bug we're not writing the env file out on --no-modify-path - I'm working on a test (and from there a fix) right now.

I got bitten by this too. Is there a way to work around this, perhaps by forcing the script at https://sh.rustup.rs/ to download an older version?

@detly :: The issue was already fixed but it was not released yet.

Meanwhile, you can simply reinstall Rust and copy the env file somewhere else so that you can source it yourself.
However, when you try to reinstall Rust, you may eventually find a problem: the env file may not be created.

This happens because rustup detects that your $HOME/.profile and $HOME/.bashrc have already been changed.
Simply edit your $HOME/.profile and $HOME/.bashrc and remove the line in the end which sources your env file at $HOME/.cargo/env.

Then run rustup once again like shown below and it should create $HOME/.cargo/env.

$ curl https://sh.rustup.rs -sSf | sh -s -- -y

Note: I have a shell script which installs Rust and several cargo plugins which circumvents this trouble.
I simply create $HOME/.cargo/env by hand via this bash function:

function __install_rust_rustup_issue_2578 {
cat << EOF > "$HOME"/.cargo/env
#!/bin/sh
# rustup shell setup
# affix colons on either side of \$PATH to simplify matching
case ":\${PATH}:" in
    *:"\$HOME/.cargo/bin":*)
        ;;
    *)
        # Prepending path in case a system-installed rustc must be overwritten
        export PATH="\$HOME/.cargo/bin:\$PATH"
        ;;
esac
EOF
}

@frgomes Unfortunately I'm using rustup as part of a hosted, cross-compiling build system. It's not a manual process, so I can't apply your advice (thanks anyway though). For now I can just populate the file as part of the build process and remove that when the fix is released.

The fix should now be live (1.23.1), please let me know if it's not working for you.

Thank you very much @kinnison. I can confirm it works at least for my use-case!

@marmeladema You're very welcome.

Was this page helpful?
0 / 5 - 0 ratings