Controlling where rustc and cargo are installed

help
1

I work in an organization that maintains all software in shared repositories accessible via NFS. In order to access said software, we have a system for defining a runtime environment based on a set of software versions configured particular task / role. A user accesses executables via a wrapper, which invokes an intermediate application to look up the runtime dependencies associated with a particular task / role, configure the environment appropriately, and then invoke the wrapped application in said initialized environment.

We do not allow individual developers to install software to their home directories. In fact, direct access to the internet is restricted to build machines and the like.

I don't really see how to install rust and cargo in this scenario. Especially since I probably need to locate the various executables from ./cargo/bin in a different location than the rest of the .cargo contents. I have seen mention of CARGO_HOME and RUSTUP_HOME, but they aren't granular enough for my needs ( or so it would seem )

Thoughts?

2

During the initial install, set CARGO_HOME and RUSTUP_HOME to somewhere in your NFS filesystem. On user machines, add whatever you used for $CARGO_HOME/bin to the user's PATH and also set RUSTUP_HOME. Don't set CARGO_HOME, as that's where cargo caches lots of things at build time. You probably want to set CARGO_HOME again in the future if you use rustup to install any updates.

Alternatively, you can install without rustup, see Redirecting...

1 Like
3

Since a user would invoke cargo via our wrapper, I suppose that i wouldn't need to set RUSTUP_HOME after building the package either.

eg, if i have rust-1.32 toolchain installed in a package, I can invoke it explicitly through our wrapper:

/tools/bin/cargo --dd version=1.32 build

unless RUSTUP_HOME is used by other tools than rustup

4

The binaries that rustup places in CARGO_HOME are wrappers that allow the user to specify the toolchain (like cargo +1.32.0 run or cargo +nightly build). These wrappers use RUSTUP_HOME. I think with your custom tooling mechanism you should avoid using these wrappers and you can directly call out to the binaries in $RUSTUP_HOME/toolchains/*/bin/.

5

I see. Thanks!

6

.. Your developers do not have internet access?

1 Like
7

No they do not. At least not the ones who work in production, based on industry guidelines:

Prohibit production network and all systems that process
or store digital content from directly accessing the
internet, including email.

8

In other words... Your developers don't have API reference access? Just curious...

9

I think all of you are talking past each other.

Presumably @jlgerber meant "access to the internet is restricted on build machines and the like."

10

Ah, so you mean kind of server specifically meant to compile code? That seems logical!