Hi Eduardo,
I'll tell you immediately that I don't use Emacs, but let's see if I can help.
On Fri, Feb 06, 2026 at 08:39:52PM -0300, Eduardo Mercovich wrote:
> Dear all.
>
> I'm very new to guix, so forgive me if my question is clearly answered out
> there and I cannot even identify where or which the answer is. I prefer to
> be very explicit and not assume anything as obvious. :)
>
> From reading the documentation and a previous reference on this list about
> virtual machines that I'm still trying to make work, I understand that in
> guix we can have different, parallel software installations coexisting in
> different /environments/, each and all of them independent and documented in
> a way that can be reproduced in other computers.
(...)
One of the things that helps and hinders us in Guix is that it's a very
different approach. It can be quite difficult to understand initially, but it
will make sense in the end.
Your statement about "parallel software installations coexisting in different
environments", needs some clarification I think.
Each unique software package in Guix is built and placed in the Store
(/gnu/store). This means that if any aspect of a piece of software is different
(for example a different version) then when built it will be placed at a
different location in the Store. That means you can build all sorts of
different variations of a piece of sofware on your system. In that sense you
can have multiple parallel builds of the same software on the computer.
When a user installs some a package, they're creating a link between their
default `guix profile` and the relevent Store directory.
Changing gears. As 'a user' when I install a package, what I'm expecting is a
binary (e.g. emacs) will show-up in my $PATH. So the slight problem with the
idea of "parallel installation" is that if you tried to install two emacs
packages they'd fight over placing the binary called 'emacs' in the same place
on your hard-drive (in the default Guix profile).
To install multiple "parallel software installations (for the user)" there are
two ways (or maybe three) ways. You can use custom 'profiles', but the easiest
way is guix shell and a "container". This will create a temporary 'pretend'
environment:
guix shell --container --network emacs coreutils
[env] emacs
Actually, when a user runs a program they need both the package and their
personalised configuration. This is where I was a bit concerned about your
"installations coexisting in different environments, each and all of then
independent". Yes, we can do that, but I'm not sure it's necessary for your
goal.
Your goal, is to run two different configuration files, it can be the same
'emacs' binary.
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. I
know nothing about emacs [0], but it looks like it would be something like:
# creat a 'new' configuration location
$ cp ~/.config/.emacs ~/.config/.emacs-new
# start your new config
$ emacs --init-directory ~/.config/emacs-new
# start your old config
$ emacs --init-directory ~/.config/.emacs
Often, people have shell aliases to then start the program with a particular
configuration: this is how I start my email client, one alias does it with a
'work' set-up, the other alias with a 'home' setup.
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:
# create the new location config file like above
guix shell -S /home/<user>/.config/.emacs-new=.config/.emacs emacs coreutils
It's a little fiddly, personally I use 'guix shell' for installing applicatons
that I need for a specific project. The earlier option of different config
files and a shell alias is what I would probably use.
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.
Hope this is what you were looking for,
Steve / Futurile
[0]
https://www.reddit.com/r/emacs/comments/yfe40i/what_is_everyones_favorite_way_of_trying_out_an/
> So I have my current emacs installation, with it's literate configuration
> consisting in just a few org files that is almost working. I'd like to
> install a newer emacs version in a new environment and try to move there,
> piece by piece, my configuration.
>
> This operation may serve 2 purposes:
>
> 1. identify the small places with issues to iron out in the configuration
> while in parallel my current emacs allows me to keep working as it is.
>
> 2. document that installation so that when I migrate the whole machine to
> guix, it should be only a matter of copying that installation documentation
> and it should install and run exactly the same.
>
> If this assumption is right, is...
>
> - "The Isolated Build Environment" the relevant place to read in the
> documentation
> (https://guix.gnu.org/manual/1.5.0/en/guix.html#The-Isolated-Build-Environment),
>
> - the "3.8 Installing Guix in a Virtual Machine"
> (https://guix.gnu.org/manual/1.5.0/en/guix.html#Installing-Guix-in-a-VM)
> which I think is the previously one referenced on this list, or
>
> - yet another?
>
>
> As always, thank you very much not only for the information, but for the
> convivial feeling of this community. :)
>
>
> Warm regards...
>
>
> --
> eduardo mercovich
>
> Donde se cruzan tus talentos con las necesidades del mundo, ahí está tu
> vocación. (Anónimo)
>
>
