What's the difference between a shell environment and a profile?

What's the difference between a shell environment and a profile?

[Konrad Hinsen]

Hi Guix experts,

While doing some software archeology, I ran into a behavior that I don't
quit understand.

First, I tested some Python 2 scripts in a shell environment:

    guix time-machine -C ./channels.scm \
        -- shell --container \
           python2 python2-mmtk python2-matplotlib \
           --with-input=python2-numpy=python2-numpy@1.8.2 \
           -- python

Works fine. Next, I wanted to create a Guix profile with the same
software, mainly to keep it in the store for long-term future use,
surviving garbage collection:

    guix time-machine -C ./channels.scm \
        -- package -p ./python2-profile \
           -i python2 python2-mmtk python2-matplotlib \
           --with-input=python2-numpy=python2-numpy@1.8.2

Guix wasn't happy at all with this:

  guix package: warning: Consider running 'guix pull' followed by
  'guix package -u' to get up-to-date packages and security updates.

  The following packages will be installed:
     python2            2.7.18
     python2-matplotlib 2.2.5
     python2-mmtk       2.7.13

  guix package: error: profile contains conflicting entries for glib
  guix package: error:   first entry: glib@2.70.2 /gnu/store/64bdjb3nwdkadmy5z2wph9cgqr0bwijm-glib-2.70.2
  guix package: error:    ... propagated from cairo@1.16.0
  guix package: error:    ... propagated from python2-pycairo@1.18.2
  guix package: error:    ... propagated from python2-matplotlib@2.2.5
  guix package: error:   second entry: glib@2.73.3 /gnu/store/kf488k7v0lc48ylbs4xxpam0dbl3r4jl-glib-2.73.3
  guix package: error:    ... propagated from gobject-introspection@1.73.1
  guix package: error:    ... propagated from python2-matplotlib@2.2.5
  hint: You cannot have two different versions or variants of `python2-matplotlib' in
the same profile.

In the end I did:

    guix time-machine -C ./channels.scm \
        -- shell --container -r ./python2-profile \
           python2 python2-mmtk python2-matplotlib \
           --with-input=python2-numpy=python2-numpy@1.8.2 \
           -- python

which should have the effect I am looking for, but I don't understand
how this differs from the "guix package" attempt that failed. The
difference seems to be related to the –with-input transform, because
I don't see what else could cause the "two different versions of
python2-matplotlib" to be around.

Any ideas?

Cheers,
  Konrad

Re: What's the difference between a shell environment and a profile?

[Simon Tournier]

Hi Konrad,

On Fri, 08 Dec 2023 at 17:24, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:

> First, I tested some Python 2 scripts in a shell environment:
>
>     guix time-machine -C ./channels.scm \
>         -- shell --container \
>            python2 python2-mmtk python2-matplotlib \
>            --with-input=python2-numpy=python2-numpy@1.8.2 \
>            -- python
>
> Works fine. Next, I wanted to create a Guix profile with the same
> software, mainly to keep it in the store for long-term future use,
> surviving garbage collection:
>
>     guix time-machine -C ./channels.scm \
>         -- package -p ./python2-profile \
>            -i python2 python2-mmtk python2-matplotlib \
>            --with-input=python2-numpy=python2-numpy@1.8.2
>
> Guix wasn't happy at all with this:

Guix is not happy with ’shell’ but pass silently the collision; from my
understanding.

Somehow, then the Python script works but by chance, I guess.


>   guix package: error: profile contains conflicting entries for glib
>   guix package: error:   first entry: glib@2.70.2 /gnu/store/64bdjb3nwdkadmy5z2wph9cgqr0bwijm-glib-2.70.2
>   guix package: error:    ... propagated from cairo@1.16.0
>   guix package: error:    ... propagated from python2-pycairo@1.18.2
>   guix package: error:    ... propagated from python2-matplotlib@2.2.5
>   guix package: error:   second entry: glib@2.73.3 /gnu/store/kf488k7v0lc48ylbs4xxpam0dbl3r4jl-glib-2.73.3
>   guix package: error:    ... propagated from gobject-introspection@1.73.1
>   guix package: error:    ... propagated from python2-matplotlib@2.2.5
>   hint: You cannot have two different versions or variants of `python2-matplotlib' in
> the same profile.
>
> In the end I did:
>
>     guix time-machine -C ./channels.scm \
>         -- shell --container -r ./python2-profile \
>            python2 python2-mmtk python2-matplotlib \
>            --with-input=python2-numpy=python2-numpy@1.8.2 \
>            -- python
>
> which should have the effect I am looking for, but I don't understand
> how this differs from the "guix package" attempt that failed. The
> difference seems to be related to the –with-input transform, because
> I don't see what else could cause the "two different versions of
> python2-matplotlib" to be around.

It does not differ.  What differs is that “guix shell” raises nothing
for the collision – maybe “guix shell” does not check the collision, I
do not remember – when “guix package” raises an error for the same
collision.

Well, since it is a past Guix revision provided by the file
channels.scm, I do not know if this collision could now be fixed.

Cheers,
simon

Re: What's the difference between a shell environment and a profile?

[Ludovic Courtès]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> It does not differ.  What differs is that “guix shell” raises nothing
> for the collision – maybe “guix shell” does not check the collision, I
> do not remember – when “guix package” raises an error for the same
> collision.

Indeed, ‘guix shell’ does not check collisions, for “historical
reasons”.  Perhaps something worth fixing at some point:

  https://issues.guix.gnu.org/54350

Ludo’.

Re: What's the difference between a shell environment and a profile?

[Konrad Hinsen]

Hi Simon and Ludo,

>> It does not differ.  What differs is that “guix shell” raises nothing
>> for the collision – maybe “guix shell” does not check the collision, I
>> do not remember – when “guix package” raises an error for the same
>> collision.
>
> Indeed, ‘guix shell’ does not check collisions, for “historical
> reasons”.  Perhaps something worth fixing at some point:
>
>   https://issues.guix.gnu.org/54350

Thanks for pointing out this behavior, which I find surprising but
understandable for the use case of development environments (although I
didn't expect collisions to be so frequent even in that context).

The problem I have now is how to update my recommendations for
computational scientists, which can be summarized as "run all research
computation in "guix shell" (see
e.g. https://10years.guix.gnu.org/program/#guix-as-a-tool-for-computational-science). As
I just found out, I am recommending people to switch off an important
level of error checking.

I'll think about this a bit and then perhaps comment on the old issue
thread!

Cheers,
  Konrad.