Hello Steve!
Thank you so much for taking this so seriously... :)
[...]
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.
Very much like emacs actually... ;P
Your statement about "parallel software installations
coexisting in different environments", needs some
clarification I think.
Absolutely. I was trying to express the need in a non-specific
way because certain words have very specific meaning in this
field.
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.
And it is what I want to, great. :)
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).
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).
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
The mentioned shell, yes...
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.
No, here I wasn't clear enough, sorry...
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).
Hope this is what you were looking for,
Yes, as this discussion is worth at least as much as the final
result when we get there, thank you very much...
And I do hope it help other new guix users in the future too. :)
--
eduardo mercovich
Donde se cruzan tus talentos
con las necesidades del mundo,
ahí está tu vocación.
(Anónimo)
