Toolbox conceptual model

Not a Toolbox dev, but I can tell you about my use case. If the goal is proper containerization, you can use Podman proper for that. However, you can not (easily) use Podman if you, say, want to install Ruby gems or Python or Rust packages that you want available outside of the Toolbox, but that needs, say, gcc and/or other tools to install. Concrete example: I’ve installed Ansible inside a Toolbox with python -m pip install --user ansible for the express purpose of making it easily available outside of the Toolbox (it needs a compile step even if it’s mostly Python). Your expectation for Toolbox would make this workflow impossible. This saves me both the hassles of running everything in containers and layering packages like compilers on top of the main Silverblue image, and allows applications that need compiling to be installed in HOME. I use this strategy for Ruby on Rails development as well and it’s by far the best workflow I’ve had. (Old school local means lots of dnf packages for compilers and runtimes, Vagrant is too slow, Podman is a poor fit for Rails, etc. - Toolbox is the only tool I’ve really liked.)

That said, this has been discussed before. For instance, you can (although it’s cumbersome and non-intuitive) use a subdir or a different path entirely as a Toolbox’s HOME. Here’s one thread that discusses this: Is it possible to create a Toolbox with its own separate home directory? - #5 by rugk. Also, there’s some relevant discussion in this Github issue: Adjust home path · Issue #348 · containers/toolbox · GitHub