When I tried installing Rust on distrobox, it installed itself on ~/.cargo/bin/rustc? How to fix?

Aurora
1

Why I think it’s unintended behavior is because when I installed PHP & Composer inside another container, it installed them on /usr/bin/composer and /usr/bin/composer (not on my host /usr, I ls’d and grep’d to check) respectively and cannot be accessed from the host machine.

But when I try to install Rust, distrobox installed it on ~/.cargo/bin/rustc (my host ~), and even after I deleted the Rust container it stayed on ~/.cargo/bin/rustc. Not to mention Rust is accessible from my host machine.

What can I do to prevent this? I know distrobox create --home ~/Documents/rust-box -n rust-box exists, but distroboxes are supposed to be disposable and I dunno if giving a box its own home directory can be considered disposable. Plus I don’t know if it will delete the stuff in its given directory after deletion.

Or is this supposed to be intended behavior?

2

This is totally fine.

Distrobox is a convenience script that mounts your home directory transparently, there will be use cases where you don’t want this.

The box is still disposable you’re just keeping its data separate.

3

You can try adjusting the cargo dir config by changing the associated env vars inside of your distrobox. To aid with things like that I usually set the hostname to the name of the distrobox like this:

alias box='distrobox enter -a --env=HOSTNAME=fedora41-python-dx fedora41-python-dx -- bash'

With that done it is straightforward to put conditional logic in the .bashrc scripts based on HOSTNAME.

In your case,

if  [ "$HOSTNAME" = "rust-box" ];then
# set the CARGO_HOME, etc. env vars as you would like them.
fi

Here is the env var ref for cargo:

But, if it were me, I would just let my host HOME dir be mounted and accept the defaults. That is what I do for 99.999% of the programming tool chains I use.

Pros:

  • shared across distrboxen - I often have project specific containers with customized sets of tool chains based on that project’s needs (installed via dnf / apt / apk / curl or equiv.)
  • centralized config - I setup things like env vars one time on my host and get the benefit of that in all distrboxen / devcontainers;
  • I have a repo in a git server on my LAN called local-config where I manage my ~/.bashrc, ~/.local/.bash.d/ scripts, ~/.config/, etc.;
  • if I need to override something in one container that is easy using the approach I mentioned above

Con:

  • if a tool chain cannot isolate packages for each tool chain version some how, I need to accommodate that by forcing it to use /usr/local or some other prefix in the container outside of my home dir. But, I have only needed to do that once. I immediately challenged myself to find a different - more modern - tech stack. :wink:

And then when I am done with that project, I tear down the distrobox because it is no longer needed. I have automation to create / re-create them so, in 6 months when I need to pick it up again, I review the script that creates it, update it if necessary and run it. In a few minutes I am back where I was.

I created this project to explain what those scripts look like and why.