Hi Steve, I just wanted to add some words to your explanation of guix shell. I know you already understand this, because you discuss the differences on your site[1].
On Fri, Feb 13 2026, Steve George wrote: > If it's just for one program then `guix shell` should be sufficient > for the job. The use of the word 'shell' is an overloaded term, but > it's basically because there's `nix shell` so a lot of users > understand it. Guix Shell creates a separated environment, it's uses > Linux namespaces - it's somewhat 'less' than a full VM. The most > common use-case you find for it is to install different tools for > different projects I found this paragraph a bit unclear, it might be worth clarifying: guix shell is a way to add packages into your environment, optionally isolated from the rest of your system. It has multiple modes: - bare "guix shell", which adds packages to the environment by adding to your existing environment variables (no isolation from the rest of your system) - "guix shell --pure", which adds packages to the environment by overriding your existing environment variables (weak isolation from the rest of your system; the only packages available are the ones in your manifest, but you can still reference anything on your system) - "guix shell --container", which adds packages to the environment by creating isolated Linux namespaces with access to the current working directory, and the required paths in /gnu/store (stronger isolation from the rest of the system; software running in the shell can only access things explicitly exposed to it) I can't comment about how others use it, but I almost exclusively use the bare "guix shell" with no isolation. I mostly build project-specific development environments where I still want to access the rest of my system. Carlo [1]: https://www.futurile.net/2023/04/29/guix-shell-virtual-environments-containers/
