cargo defaults to installing things in ~/.cargo

[asmeurer]

The cargo package manager that ships with rust defaults to installing things in ~/.cargo/. This seems antithetical to the idea of conda environments.

Maybe this is more of a cargo issue than a conda-forge issue. Whoever's issue it is, I think the conda cargo (if not cargo in general) should be installing things into the conda environment it is installed in by default, the same as pip and most other language specific package managers.

[pkgw]

Hmm. I think that I agree with the general idea here.

In terms of implementation, I think that we would have to override $CARGO_HOME in our Rust environment setup, which wouldn't be hard.

It is true that $CARGO_HOME is mostly about caching (cf cargo home docs) and it would get pretty inefficient to have multiple Cargo caches for every environment. My ~/.cargo directory is currently 4.2 GiB. The other tradeoff that I worry about is just that most users and tools will expect $CARGO_HOME to have the default value and changing it might cause unnecessary headaches.

Anyone else have any thoughts?

[asmeurer]

There are two potential complications:

• The environment might be read only. While for most users it isn't, for some installations it is due to permissions. In that case, if it is used for caching, that would fail even if the install location is somewhere else.
• Environment variables might not be defined if the environment is never activated, e.g., for the root environment, or if someone manually calls /path/to/env/bin/cargo. So it's better to not rely on environment variables for conda packages if possible.

This issue should probably be discussed with the cargo community as well. I just wanted to make the conda forge maintainers aware of the issue. I am not really a Rust or cargo user (I just used it to install one package the other day), so I don't really want to spend too much effort on this myself.

[pkgw]

Our Rust packages just repackage the official Rust builds, because they're relocatable and compiling everything ourselves would be super unpleasant, so we're probably going to have to rely on environment variables to modify any behavior like this. Unless Cargo recognizes some magic prefixed configuration files, which I don't believe to be the case (but I haven't checked).

[davidlattimore]

If you wanted to have a separate $CARGO_HOME, but still share cached artifacts, perhaps you could have symbolic links from $CARGO_HOME/registry and $CARGO_HOME/git to their respective default locations. Then they would be shared, but $CARGO_HOME/bin would be separate. That's assuming it's possible to create directory structure at an appropriate time before cargo gets run?