Add shared toolchain directories #4967

Activity

1. Rx1513

   added

   enhancement

   on Jul 20, 2026
2. rami3l commented on Jul 20, 2026

   

   rami3l

   on Jul 20, 2026

   Last edited by rami3l

   Member

   More actions

   Although it is possible to manually link a system toolchain, there is no mechanism to keep it synchronized with updates from the package manager.

   @Rx1513 Hello! My apologies but I'm not quite sure what are you looking for with this proposal.

   As I understand it, since it's a link, a linked system toolchain from the package manager is automatically synchronized with updates from the package manager.

   rustup should automatically discover toolchains from the shared directory.

   Why would batch-assigning a directory of linked toolchains simplify your workflow? Could you please elaborate?

   To solve these issues, a separate shared directory managed by external tools could be added.

   Should it be the responsibility of the external tools, whatever they may be, to add such links?

   PS: We are avoiding adding more layered configurations so I would prefer being more careful with that part of your proposal, and it's vital that we reach an understanding of what exactly is needed in your use case.

   PPS: If you are referring to using project-specific sets of tools under a specific name, I have this proposal that may suit your needs: #4636
3. Rx1513 commented on Jul 21, 2026

   

   Rx1513

   on Jul 21, 2026

   Author

   More actions

   Although it is possible to manually link a system toolchain, there is no mechanism to keep it synchronized with updates from the package manager.

   @Rx1513 Hello! My apologies but I'm not quite sure what are you looking for with this proposal.

   As I understand it, since it's a link, a linked system toolchain from the package manager is automatically synchronized with updates from the package manager.

   The problem is that each link is handled manually.

   • If the package is removed, rustup still lists the linked toolchain until the user manually removes the link.
   • When the package manager installs a package, user must manually link the distributed toolchain and then select it. It may sound simple but in practice it looks something like this:

   apt-get install rust
   Look where package places its toolchain
   rustup toolchain link <user-specific name> <generally long absolute toolchain path>
   rustup default <user-specific name> || rustup override set <user-specific name>
   # Done
   

   Two middle steps seems very unnecessary as it requires new useless information for user and some extra steps, especially when compared to official toolchains installation:

   rustup default
   # Done
   

   What I want is to make usage of system's toolchains is similar to usage of official toolchains:

   apt-get install rust
   rustup default <distro specific name> || rustup override set <distro specific name>
   # Done
   

   or even:

   apt-get install rust
   # Done
   

   In my opinion the additional lookup directory should create much smoother user experience when dealing with toolchains from other external sources.

   Why would batch-assigning a directory of linked toolchains simplify your workflow? Could you please elaborate?

   It doesn't require from each user doing manual tedious work. It helps separate responsibilities: external tools manage external directories under administrator control, while the user's home directory remains solely the user's responsibility.

   To solve these issues, a separate shared directory managed by external tools could be added.

   Should it be the responsibility of the external tools, whatever they may be, to add such links?

   As far as I know many Linux distributions discourage when package manager messes with home directory so it's not the way. The only way is if user manually links every external toolchain or if administrator does it for them, which yet again messes with responsibility.

   PS: We are avoiding adding more layered configurations so I would prefer being more careful with that part of your proposal, and it's vital that we reach an understanding of what exactly is needed in your use case.

   I think this feature keeps the configuration largely unchanged. It only adds an additional lookup directory for externally managed toolchains, while the existing per-user links continue to work unchanged.

   PPS: If you are referring to using project-specific sets of tools under a specific name, I have this proposal that may suit your needs: #4636

   I don't think this is related to the problems I'm addressing here, but thanks for help.
4. rami3l commented on Jul 21, 2026

   

   rami3l

   on Jul 21, 2026

   Member

   More actions

   @Rx1513 Thanks for your detailed reply! As I roughly understand it, you are referring to adding support for a new toolchain directory for automatic toolchain discovery (but read-only)?

   When the package manager installs a package, user must manually link the distributed toolchain and then select it.

   IRRC rustup treats every folder under the toolchain directory as a valid toolchain, so I am curious about how we could probably make it work with your case.

   What is your specific distro/external tool that installs externally-managed Rust toolchains in a way that is compatible with your new directory proposed here? For Homebrew (what I'm using) for example, the system Rust toolchain is installed alongside other packages. Is rustup supposed to distinguish between those?

   I'm not opposed to adding a new folder in the current rustup installation layout of some sort that you can possibly link a local directory to, IMHO the most important thing here is still what tool you are trying to make rustup work with.

   I think this feature keeps the configuration largely unchanged. It only adds an additional lookup directory for externally managed toolchains, while the existing per-user links continue to work unchanged.

   Not quite; the alt-nightly-1.95 (shadowed) in your previous example might indicate that alt-nightly-1.95 has different semantics under different situations, that is exactly the kind of extra complexity we would like to avoid.
5. Rx1513 commented on Jul 27, 2026

   

   Rx1513

   on Jul 27, 2026

   Author

   More actions

   @Rx1513 Thanks for your detailed reply! As I roughly understand it, you are referring to adding support for a new toolchain directory for automatic toolchain discovery (but read-only)?

   When the package manager installs a package, user must manually link the distributed toolchain and then select it.

   IRRC rustup treats every folder under the toolchain directory as a valid toolchain, so I am curious about how we could probably make it work with your case.

   What is your specific distro/external tool that installs externally-managed Rust toolchains in a way that is compatible with your new directory proposed here? For Homebrew (what I'm using) for example, the system Rust toolchain is installed alongside other packages. Is rustup supposed to distinguish between those?

   ALT Linux which uses apt-rpm. Currently we package our rust distribution in /usr/lib64/rust-toolchains and provide symlinks to it. So if you install rust and rustup and then replace /usr/bin/ toolchain symlinks with rustup proxies and then link toolchains you will be able to use both official and system's toolchain.

   I'm not opposed to adding a new folder in the current rustup installation layout of some sort that you can possibly link a local directory to, IMHO the most important thing here is still what tool you are trying to make rustup work with.

   Package manager, nfs, rsync directories or any other ways to distribute compiled artifacts which rustup is able to treat as a toolchain.

   I think this feature keeps the configuration largely unchanged. It only adds an additional lookup directory for externally managed toolchains, while the existing per-user links continue to work unchanged.

   Not quite; the alt-nightly-1.95 (shadowed) in your previous example might indicate that alt-nightly-1.95 has different semantics under different situations, that is exactly the kind of extra complexity we would like to avoid.

   I understand the concern about added complexity. However, the (shadowed) tag is simply an indication that a shared toolchain has a conflicting name with a user's toolchain, meaning the user's toolchain will take precedence. Without this indication, it wouldn't be obvious why the shared toolchain isn't being run. Although I may be wrong here, since I had forgotten that the active toolchain is already marked as (active), which may already provide enough context.
6. rami3l commented on Jul 27, 2026

   

   rami3l

   on Jul 27, 2026

   Last edited by rami3l

   Member

   More actions

   @Rx1513 Thanks for sharing the context!

   I think in this case I can allow say linking toolchain/+sys to /usr/lib64/rust-toolchains, and then you can call your new toolchain as sys/alt-nightly-1.95. Then an extra CLI interface can be provided, say rustup toolchain link --dir sys /usr/lib64/rust-toolchains

   This is possible because the + prefix has been allowed for toolchain names in #4650 plus / is not allowed in regular custom toolchain names, so that will not cause name clashes with existing toolchains.

   Do you think that would be a better compromise?

   However, the (shadowed) tag is simply an indication that a shared toolchain has a conflicting name with a user's toolchain, meaning the user's toolchain will take precedence.

   That is correct. What I want to say here is that I would prefer not to create precedence in new features, unless proven absolutely necessary.
7. Rx1513 commented on Jul 28, 2026

   

   Rx1513

   on Jul 28, 2026

   Author

   More actions

   I think that's a great compromise! But wouldn't it also allow relative paths that were prohibited in 2c9297d? I think the implementation should be extremely strict about which patterns are allowed, rejecting any extra /, ., or .. components.
8. rami3l commented on Jul 28, 2026

   

   rami3l

   on Jul 28, 2026

   Last edited by rami3l

   Member

   More actions

   @Rx1513 Would you mind elaborating? IIRC relative links means that the link targets are relative, but in this case link targets are absolute. foo/bar just looks for a toolchain located at $RUSTUP_HOME/toolchains/+foo/bar, and $RUSTUP_HOME/toolchains/+foo must link to an absolute target.

   I don't think we will allow other kinds of components; / is just a separator and is only allowed to appear once.
9. Rx1513 commented on Jul 28, 2026

   

   Rx1513

   on Jul 28, 2026

   Author

   More actions

   I meant that rustup should reject any path traversal like +foo/../../malicious/bar or +foo/bar/../../malicious/bar so rustup behaves exactly like you described it.
10. rami3l

    self-assigned this

    on Sep 3, 2026