Make rustup works also on read-only filesystem (at least for storage)

[siscia]

Describe the problem you are trying to solve

It would be interesting to have a way to rustup works also with read-only directory.
In particular it would be interesting to have rustup use the big files (compiler/toolchain) from a read-only directory while the configuration file would need to stay in a different (writable) directory.

Describe the solution you'd like

If we could add a env variable to point rustup to either: the configuration file or the "storage directory".
Both solution will work, even if the most interesting would be to have two variables, one for the configuration file and the other for the storage directory.

Notes

I briefly discussed this request on reddit with @danielsilverstone-ct but I didn't have time to actually put it as github request, anyhow, references here: https://www.reddit.com/r/rust/comments/d1qxj4/rustup_1190_released/ezq6fvj/

Why it is usefull
Complex distribution/installation models rely on provide a shared read-only directory where common software/files are installed.
This is very common in HEP (High Energy Physic) research, but also in HPC in general.

In am not aware of any open-internet server that allow this approach to anybody, but I am in the (slow) process of setting up one myself and I could provide an example of how this kind of systems work. Indeed are not very widespread in the industry.

[kinnison]

Hi! (you discussed with me, not my work-based alter-ego)

rustup is meant to work by installing toolchains for itself. If you want the toolchains to be present on read-only storage you can use rustup toolchain link to link to existing toolchains. For example on Debian I might use rustup toolchain link system /usr to link the apt installed toolchain.

I don't think that there's anything we need to do with rustup per-se, except perhaps for documenting how to use toolchain link a bit more.

What do you think?

[rbtcollins]

I think we'd need to understand a bit more about the user model here.

How would mutating commands work: would they write to a different writable store, or would they error?

How would the central store be updated?

This is basically the same 'share a rustup installation' bug I closed yesterday in another form, but perhaps one with clearer citations :P. I think an RFC is needed basically.

[siscia]

In HPC environement is common to have common software installed on a read-only directory shared in all the host via NFS or similar.

Compilers and toolchains are great candidate for this model since they take long time to build and don't need to change often, moreover, it allow developers to quickly test their code against different compilers, a common use case is to test different version of gcc or clang vs gcc vs intel.

This, however requires that the whole toolchain can live in a read-only directory.

Usually there is a "backend" read-only directory that contains the software, and a writable directory that contains the symlinks. Or environment variables that steer the PATH for the compilers to the read-only directory.

I was opning this issue since I work on one of those read-only filesystem.

[siscia]

@rbtcollins and yes, the use case is similar to this one #2383

It is quite common in a lot of environments honestly.

[rbtcollins]

Sure, ish. I mean - the use case for an individual developer is quite different to HPC grid jobs: an individual developer can install rust via rustup in a minute or so, including download time. Doing that in every job on every machine in a large cluster is relatively inefficient though and some form of caching is quite desirable, which is why e.g. docker caches, local image registries, NFS servers etc exist.

Nevertheless, the questions I've raised are important: for rustup to grow to be useful for this usecase, we need to have a decent user model for working with it, one that doesn't break the user model of the individual developer / CI use cases, which is where rustup's focus has been thus far.

[siscia]

Let me get a better hang on the internal of rustup.

Being a compiler multiplexer it will make possible to store the big compiler toolchain in the RO filesystem and let rustup modify the local environment to point to the RO filesystem.

[siscia]

Maybe I am mistaken, but could it be as simple as rustup toolchain link test-ro /some-read-only-dir/toolchain ?

[rafedramzi]

I have another use case for this as a developer. I'm using vscode to write rust, my IDE have "Go to definition" feature to see the actual implementation of a function by opening the corresponding file and that's the problem, every time it open a file from standard library, I'm afraid that I might accidentally edit the standard library.

My suggestion is to create a rustup user and group and set the sticky bit on on the rustup binary and make the toolchain and update-hashes owned by rustup.

[kinnison]

Creating multiple users etc. would be more complex than we can sensibly handle in rustup itself. We have talked about having the source code as a zip file or similar before now, simply because of how long it takes to unpack the docs and source on some platforms; however I don't think IDEs, browsers, etc. can cope with that. In theory if you don't do anything which would cause rustup to write to anything, it ought to work on a read-only filesystem though.

[rbtcollins]

We will soon require a lock mechanism for ensure update safety across concurrent update calls; that may require write permissions even during read operations, though we can probably make it fallback if this is a supported use case.

Also we'll need a IPC mechanism - e.g. a domain socket or pipe or the like - for dealing with update notifications in the near future.

[kinnison]

True, though we can warn and fall back I suppose for both :D