a first question about parallel environments

a first question about parallel environments

[Ben]

Hi all
I've watched all the introduction videos (which are really helpful) and red some documentation, but I think I still miss something fundamental.

I run a vagrant vm with a simple node server app behind apache.  The setup is small, but still has a some configuration and packaging (npm) involved. So I'd like to try to introduce guix into this setup. In addition to that I have a second vagrant vm running with the same basic setup, but some minor differences. 

Would it be possible to put these two setups from two different vagrant machines into one machine? I don't need strong isolation, but I need the possibility of having different versions of software installed on a single vagrant vm.

If it is possible I would like to keep using vagrant. I know about docker, but in this case the preferred way would be: a vagrant vm with guix installed with a couple of parallel environments (if thats the correct term).

When reading about guix I always imagine the case when you're sitting infront of your linux notebook, something (package, dependency) breaks and now thanks to guix you're able to roll back very easily. So this would be a single user environment. But can guix also be helpful in a case where you have multiple different environments (I hope the term is correct) running in parallel? What is the best way to achieve that? Creating multiple users? Using containers?

Thanks
Ben

Re: a first question about parallel environments

[John Soo]

Hi Ben,

Welcome.

> But can guix also be helpful in a case where you have multiple different environments (I hope the term is correct) running in parallel? What is the best way to achieve that? Creating multiple users? Using containers?

Certainly!  This is one of the main benefits of a functional package manager.  Environments, as you call them, are called profiles in guix or nix. They are comprised of a set of symlinks and env vars and other computed things pointing to the store. Those links are meant to be understood by shells or other tools the user or system would use (like $PATH).

By default each user has their own profile.  Moreover, you can use guix environment to create a one-off profile from a file, the dependencies of a package, or from specified ad-hoc lists of packages. I suggest giving that a try! There are even options to run your environment in a container.  The docs are quite good for guix environment so I would give them a read. 

I find this idea of profiles still quite tantalizing and of further use than it has now. We have yet a lot more to get out of this deployment approach.

Good luck!

John

Re: a first question about parallel environments

[John Soo]

Hi again,

Seems my message was cut off. 

To the point: yes it is quite possible. For the short version and to get started check out the docs for the `guix environment` command. You will probably get what you want there.

Also it does help to understand the idea of a functional package manager. You can read eelco dolstra’s phd thesis on the topic for the in depth version.  There may be other material in the guix documentation as well.

Welcome again,

John

Re: a first question about parallel environments

[nylxs]

On 2/21/20 11:37 AM, John Soo wrote:
>  They are comprised of a set of symlinks and env vars and other computed things pointing to the store. 


no security risk there :(

This is not unique to a functional init

Re: a first question about parallel environments

[Gary Johnson]

Hi Ben,

Just another humble Guix user here. I can't speak to your questions
about vagrant, but as far as parallel environments are concerned, you
are right that Guix can handle them.

The general terminology goes like so:

- A user installs packages into a profile.
- A user may combine packages into an environment.
- A profile is a saved environment.
- A user may specify which environments or profiles are active at any time.
- A user has a default profile created for them automatically by Guix,
  into which packages are installed unless specified otherwise.

Now a package is just a Scheme declaration that defines:
1. where to download the source code for a particular version of some software
2. how to patch, compile, and otherwise build it
3. some metadata like name, version, description, copyright, etc.

If you want to install multiple versions of a piece of software onto
your machine, you need a Scheme declaration for each version of that
software. That's it.

Now the trick to this is that when you pull the latest version of Guix
(e.g. "guix pull"), you get the latest version of the Guix build tools
as well as all of the Scheme declarations for every package supported by
that version of Guix. In general, the Guix distribution only provides
one version of each package.

Therefore, if you want multiple versions of something, you will have to
provide the Scheme declarations for the version(s) that are missing from
the current Guix distribution. You can so either by adding them to a
directory on your $GUIX_PACKAGE_PATH or by creating a separate channel
to serve up those packages. (See the Guix info docs about channels.)

For your particular situation, the easiest way to manage two sets of
packages installed on the same machine is just to make two user
accounts. Install one set of packages with the first user and the second
set of packages with the second user. The package files are always
stored in Guix's store directory (usually /gnu/store), so if both users
install the same package, it only exists once under /gnu/store. However,
each user's default profile will contain a set of symlinks that only
point to the packages that they installed. This provides clean isolation
between the different package versions without wasting disk space.

Messing directly with environments is another way to accomplish your
goal, but it wouldn't be nearly as easy to manage. You can create
one-off environments (collections of "installed" packages) using the
`guix environment' command. However, without saving the environments to
profiles, you would have to manually specify all the packages in your
environment each time you wanted to run a command within it. It's still
a perfectly viable path (especially if you hard-coded the long commands
into shell scripts), but using the default profile for multiple user
accounts definitely eliminates the extra DIY aspect of manual
environment/profile activation and deactivation.

Just my 2c,
  Gary

Ben <ben@srctxt.com> writes:

> Hi all
> I've watched all the introduction videos (which are really helpful) and red some documentation, but I think I still miss something fundamental.
>
> I run a vagrant vm with a simple node server app behind apache.  The setup is small, but still has a some configuration and packaging (npm) involved. So I'd like to try to introduce guix into this setup. In addition to that I have a second vagrant vm running with the same basic setup, but some minor differences.
>
> Would it be possible to put these two setups from two different vagrant machines into one machine? I don't need strong isolation, but I need the possibility of having different versions of software installed on a single vagrant vm.
>
> If it is possible I would like to keep using vagrant. I know about docker, but in this case the preferred way would be: a vagrant vm with guix installed with a couple of parallel environments (if thats the correct term).
>
> When reading about guix I always imagine the case when you're sitting infront of your linux notebook, something (package, dependency) breaks and now thanks to guix you're able to roll back very easily. So this would be a single user environment. But can guix also be helpful in a case where you have multiple different environments (I hope the term is correct) running in parallel? What is the best way to achieve that? Creating multiple users? Using containers?
>
> Thanks
> Ben


--
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html