Re: Replacing python venv - environment or profile?

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Wed, 25 Nov 2020 at 20:21, Phil <phil@beadling.co.uk> wrote:

> Yes this makes perfect sense to me, I guess what I was missing was that
> a 'guix environment' is just a temporary and special case of sourcing a
> Guix profile.

Yes, if you are curious by the internal machinery.  The default profile
~/.guix-profile is a symlink

  $ readlink -f ~/.guix-profile
  /gnu/store/z32aid8bjbz7ylwbjfh5x6lbg2g7fiv0-profile

Now compare:

  $ guix environment --ad-hoc hello
  [env]$ echo $GUIX_ENVIRONMENT
  /gnu/store/hgh67ilwsbx6v2irc7vgrnv354cv4h8a-profile

but no symlink points to the environment temporary profile, so once out,
the GC can do its job.

To end with the internals, give a look to the file:

  /gnu/store/…-profile/etc/profile

it describes how the environment variables are set.


>>   guix environment --ad-hoc python
>>   [..work..]
>>   guix pull
>>   guix environment --ad-hoc python
>>
>> Now, the first Python is not necessary the exact same than the second
>> one.  Considering the sequence,
>
> Yep you're creating two separate environments each taken from the
> current 'latest' python version.  Which may have been updated by guix
> pull for example.

Yes, exactly.


>>> $ guix environment --pure --manifest=manifest.scm --root=./test-profile
>>
>> I am not convinced you need the --root at first.
>
> This is purely a way of creating a pure environment from a manifest, and
> creating a profile from that same manifest as a one-liner (to pin the
> packages in the store).  If you'd previously created a profile with the
> same manifest this would be unnecessary.

Yes.  My point was to have at first an explanation about environment vs
profile, trying to avoid to mix all the concept in the same time. :-)


>> This create a environment, not a profile.  For a profile, you should do:
>>
>>   guix package -m manifest.scm -p ./test-profile
>
> Yep - so this does the same thing as the above, but doesn't then put me
> into a 'guix environment' referencing the same pacakges as the
> test-profile does.

I am not sure that understand what you mean.

  $ guix environment --pure --manifest=manifest.scm --root=./test-profile
<=>
  $ guix package -m manifest.scm -p ./test-profile
  $ eval $(guix package –search-paths=exact)

I almost never use the former, i.e., options -m and -r in the same
line.  And I prefer the latter.  Just a matter of taste.

However, I use “guix environment hello -r /tmp/guix”.  I let you notice
the difference. ;-)


> So, if I instantiate the environment using "--search-paths=exact" then I
> get *pure* environment variables, rather than appending or prepending to
> the current variables.

Yes, even if I do not know if “instantiate the environment” is the
correct terminology here. :-)


> So using this I don't need "guix environment --pure" anymore!  Which was
> what I wanted.

It depends.  Sometimes, you want to temporary extend a profile so “guix
environment” is really useful.  Or run in a container.  Or have all the
dependencies necessary of one package, for example:

  guix environment python-mypy --ad-hoc python-numpy


>> But if you want crazy isolation with container, you can do:
>>
>>   guix describe -f channels > my-channels.scm

Run

  guix help
  guix describe

and then the commit capture everything of Guix.  So at any point in
time, you can still run:

   guix time-machine –commit=123456 – help

and it will be the exact same code running “help” that the one running
now.  And any command works: install, environment, pack, system, etc.


>> then any point in time, you will have the exact same environment with:
>>
>>   guix time-machine -C my-channels -- environment -C -m my-manifest.scm
>
> This is snapshotting not just my manifest, but also the exact state of
> the Guix commands themselves - so the environment and the tooling for
> that environment are both replicated?

Yes.

In a repo, you have to track 2 things: the manifest.scm about the
packages you need **and** the channels.scm file which is the correct
description of their versions (and the versions of all the machinery
used to bootstrap, compile or byte-compile them).

This way, you can regenerate the exact same “environment” at any time
and any where, for example:

 guix time-machine -C my-channels -- pack -f docker -m my-manifest.scm


> Yes agreed - let's discuss later, I just wanted to give the group a
> vague idea of where I'm hopefully ultimately heading with my Guix use,
> but I must walk before I run!

Sound a cool goal!


All the best,
simon