On Fri, Feb 13, 2026 at 09:34:23AM -0300, Eduardo Mercovich wrote:
(...)
> Up to here, I got that. It is exactly why I was asking for those other ways
> to do it. A virtual machine, or a shell (a concept that I barely get, but
> can distinguish from a normal shell in Linux).
(...)
> I have a relatively new emacs version but with relatively old pieces inside,
> like mu4e, which is my MUA of choice.
>
> In order not to loose the currently working setup until I can test a new one
> (and to facilitate the full guix migration I'll do on my machine), I wanted
> to create a new container/ shell/ vm that has the most up to date emacs with
> the most up to date mu4e and it's own, separate working configuration. And
> all this documented/ expressed so it can be replicated directly on my
> computer once guix becomes the OS.
>
> > In one configuration file you'll have your 'old' configuration, and in
> > another your 'new' configuration. Technically, you don't need Guix for
> > this, you could just start `emacs` and provide it with two different
> > configuration files. [...]
>
> Yes, but as I hope is clearer now, this is not what I want. :)
>
> > To do it in a more 'Guix' way you could use `guix shell` to sort of
> > trick emacs into thinking that the configuration file is from the
> > standard location. Guix shell has a `--share` option which tells the
> > "container" have access to a file location (essentially a mount). So we
> > could start a shell and "mount" our new config where emacs expects to
> > find it's config:
>
> Yes! This is what I was asking for... how those approaches compare,
> shell and vm (and other/s, if they exist).
>
> [...]
>
> > The way to achieve the full "installations in different environment ..."
> > would be to use Guix Home. One of the things it can do is to copy a
> > specific configuration file into your $HOME environment. So pretend you
> > run two Guix VM's, and in one you run your 'old' emacs config, and in
> > another your 'new' emacs config. There would be two separate 'Guix Home'
> > configs and they would copy the files to the emacs config location.
>
> I think I got it. However, does this approach (guix home) supports
> having 2 different versions of the same software installed too?
>
> So up to now I understand that we have 3 approaches:
>
> - the shell (a container if I got it right)
>
> - a vm (a similar approach, maybe the same and I don't yet grok the words?)
>
> - guix home (a change in environmental variables).
(...)
OK, got it. In order of complexity:
1. Guix shell
2. Guix Home
3. Guix System in a VM
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 [0]
Guix shell can install packages from the archive, share directories (mounting
them in different ways) and share environment variables. You can create a
`manifest` (list of packages to install) which will mean your shell command is
easy to use and repeatable. So lets say we create a file (manifest) called
emacs-experiment.scm with the following:
(specifications->manifest
'( "emacs"
"emacs-spacemacs-theme"
"emacs-org-msg"
"emacs-helm-mu"))
The specifications->manifest procedure converts from the `name/version` field
and creates a `manifest` we can feed into guix shell (more on manifests [1])
Then guix shell would be something like:
guix shell --manifest=<file.scm>
You could use this with the alias trick from the previous email, so that in the
new 'shell environment' you'd start emacs using the newer configuration file
you're playing with.
The purpose of `guix home` is to be a full user configuration manager: if
you've seen any 'dotfiles' manager, think of it as that but pumped up with
additional capabilities. Lets say you login to multiple machines and you want
to have all your personal configuration files (e.g. ~/.config/xxx) and
'services' to be the same on each host. You would do this with Guix Home.
For your specific example it's overkill, but you can use guix-home to define
which guix applications should be installed (at a user level) and what
configuration files. Here's a simple example:
; normally kept in a 'guile module'
(use-modules (gnu home)
(gnu packages)
(gnu services)
(guix gexp)
(gnu home services shells))
(use-package-modules emacs gnupg vim)
(home-environment
;; packages to install
(packages
(specifications->packages
(list "vim" ;the only true editor
"emacs")))
;; home 'services'
(services
(list
;; configure the bash shell with some aliases
(service home-bash-service-type
(home-bash-configuration
(aliases '(("emacs-new"
"emacs --init-directory ~/.config/emacs-new/")
("emacs-curr"
"emacs --init-directory ~/.config/emacs/")))))
;; configure file that are placed into ~/.config
;; in this example theres a 'files' directory which all my templates
;; are in.
(service home-xdg-configuration-files-service-type
`(("emacs/init.el" ,(local-file "files/emacs/init.el")))))))
Without going into too much detail this uses `use-package-modules` to make some
packaging modules available then it sets up a `home-environment`. In there we
install some packages (using specifications->packages) again, and we configure
some `services` (a terrible name!). The services thingy copies files from where
you run the `guix home` command from to the new environment: in this case we
create some alises for bash (using the "bash service"), and we copy the emacs
init file into our ~/.config/emacs directory (using the
home-xdg-configuration-files-service). This example probably won't run, but it
gives you an idea.
Generally people use `guix home` to manage your existing $HOME or they could
create a Guix VM (Guix System) and use it there. But, you can actually use it
in a `guix shell` see the `guix home container` command.
Hopefully that gives you some things to try!
Steve / Futurile
[0] I wrote a blog series called `Guix for Software Developers` that you can
find here: https://www.futurile.net/resources/guix/
[1] https://www.futurile.net/2022/12/12/guix-managing-apps-with-manifests/
