Enabling certain steps to run in a container

[awesomekyle]

I use Silverblue and thus try to avoid installing tools on my host and instead use containers (through Distrobox). This works great because I'm able to install cargo packages within my container and use them on the host from my ~/.cargo/bin/ folder.

The problem is that topgrade detects cargo when running on the host and tries to run cargo-install-update, which fails with error: linker /usr/bin/clang not found (as expected). I could of course install Clang on the host to workaround this, but that defeats the purpose of using a container in the first place. I'm able to run topgrade within my container and obviously the update succeeds, but the whole point of using topgrade is that I only need to run it once and it takes care of everything. Right now my only option is to install things on the host I don't want, or disable the cargo step entirely.

I'm not sure what the right solution is, but it'd be useful if I could delegate certain steps to either an existing container or a container image that is pulled/launched automatically (such as using the official Rust Docker images to do the update). Right now my only usecase is Cargo, but I could see this being useful for other tools as containerization grows.

Another option would be to make executable names/paths configurable. Then I could set up a cargo update script that does whatever I need it to do.

[SteveLauC]

Have you tried:

$ topgrade --only distrobox

If everything you need is in the containers

[awesomekyle]

That just goes into the distrobox and runs dnf/apt/apk update/upgrade which works fine regardless. It doesn't however call topgrade --only cargo inside that distrobox. This is what I see from the host:

── 21:10:20 - Summary ──────────────────────────────────────────────────────────
System update: OK
config-update: OK
distrobox: OK
Firmware upgrades: OK
Flatpak: OK
Gnome Shell Extensions: OK
rustup: OK
cargo: FAILED
pipx: OK
pip3: OK
chezmoi: OK
Neovim: OK
Containers: OK

What I really want is something like topgrade --only cargo --exec-command "podman exec -e PATH=$HOME/.cargo/bin:$PATH main topgrade --only cargo". Running that podman command technically works from the host side, but it's obviously not ergonomic or integrated into topgrade.

[SteveLauC]

That just goes into the distrobox and runs dnf/apt/apk update/upgrade which works fine regardless. It doesn't however call topgrade --only cargo inside that distrobox.

Yeah, I am sorry, Topgrade only executes distrobox upgrade for this step. Can you ssh into a distrobox container? If so, you might be able to update the tools inside of it with Topgrade Remote