About conflicting entries in a profile

About conflicting entries in a profile

[Ivan Vilata i Balaguer]

Hi!  I've been using Guix on top of Debian for more than 2 years and I saw
something that spurred a doubt about how Guix manages conflicts.

So the other day I got the following output from ``guix package -u`` after a
``guix pull``:

    $ guix package --dry-run -u python-jsonschema
    The following package would be upgraded:
       python-jsonschema    2.6.0 -> 3.0.1  /gnu/store/va4hgdfx8zbqzyah7vgqkm25g60p8lf3-python-jsonschema-3.0.1
    
    guix package: error: profile contains conflicting entries for python-attrs
    guix package: error:   first entry: python-attrs@18.2.0 /gnu/store/awb7awycpf1crpd1kllvk6qzchd4g7lw-python-attrs-18.2.0
    guix package: error:    ... propagated from python-jsonschema@3.0.1
    guix package: error:   second entry: python-attrs@18.2.0 /gnu/store/s77kxps7sybxxdny68xkbcp51ffmiwfl-python-attrs-18.2.0
    guix package: error:    ... propagated from python-automat@0.6.0
    guix package: error:    ... propagated from python-twisted@17.5.0
    guix package: error:    ... propagated from python-txtorcon@19.0.0
    guix package: error:    ... propagated from magic-wormhole@0.11.2
    hint: Try upgrading both `python-jsonschema' and `magic-wormhole', or remove one of them from the profile.

I understand the error message, and upgrading both packages fixed the issue
indeed.  What I don't get is *why* having two different versions of
``python-attrs`` in the profile is considered an error.  My understanding was
that two different packages in the profile should be able to depend on
different versions of the same library without problems, since they are
referred by its absolute path in the store so they don't conflict.  I
understand that I may not directly ``guix install`` two versions of the same
package (because the may e.g. put the same entry under ``$GUIX_PROFILE/bin``),
but in my case ``python-attrs`` is just a dependency package which doesn't
show up in ``guix package -I``.

Can anybody shed some light on the issue?  Thanks!

PS: Yes, I started to write about this in the IRC channel but I pasted too
many command output lines and got banned.  Oops!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/

Re: About conflicting entries in a profile

[Julien Lepiller]

Le 10 mai 2019 01:53:59 GMT+02:00, Ivan Vilata i Balaguer <ivan@selidor.net> a écrit :
>Hi!  I've been using Guix on top of Debian for more than 2 years and I
>saw
>something that spurred a doubt about how Guix manages conflicts.
>
>So the other day I got the following output from ``guix package -u``
>after a
>``guix pull``:
>
>    $ guix package --dry-run -u python-jsonschema
>    The following package would be upgraded:
>python-jsonschema    2.6.0 -> 3.0.1 
>/gnu/store/va4hgdfx8zbqzyah7vgqkm25g60p8lf3-python-jsonschema-3.0.1
>    
>guix package: error: profile contains conflicting entries for
>python-attrs
>guix package: error:   first entry: python-attrs@18.2.0
>/gnu/store/awb7awycpf1crpd1kllvk6qzchd4g7lw-python-attrs-18.2.0
>    guix package: error:    ... propagated from python-jsonschema@3.0.1
>guix package: error:   second entry: python-attrs@18.2.0
>/gnu/store/s77kxps7sybxxdny68xkbcp51ffmiwfl-python-attrs-18.2.0
>    guix package: error:    ... propagated from python-automat@0.6.0
>    guix package: error:    ... propagated from python-twisted@17.5.0
>    guix package: error:    ... propagated from python-txtorcon@19.0.0
>    guix package: error:    ... propagated from magic-wormhole@0.11.2
>hint: Try upgrading both `python-jsonschema' and `magic-wormhole', or
>remove one of them from the profile.
>
>I understand the error message, and upgrading both packages fixed the
>issue
>indeed.  What I don't get is *why* having two different versions of
>``python-attrs`` in the profile is considered an error.  My
>understanding was
>that two different packages in the profile should be able to depend on
>different versions of the same library without problems, since they are
>referred by its absolute path in the store so they don't conflict.  I
>understand that I may not directly ``guix install`` two versions of the
>same
>package (because the may e.g. put the same entry under
>``$GUIX_PROFILE/bin``),
>but in my case ``python-attrs`` is just a dependency package which
>doesn't
>show up in ``guix package -I``.
>
>Can anybody shed some light on the issue?  Thanks!
>
>PS: Yes, I started to write about this in the IRC channel but I pasted
>too
>many command output lines and got banned.  Oops!

Hi,

With packages written in C for instance you're right: dependencies are directly embeded into binaries. With python however, we cannot embed store paths by default, so we use propagated-inputs instad of regular inputs. Propagated inputs are installed in the profile along with their dependant, recursively, hence the conflict.

With executable packages, we could try and wrap packages to define a PYTHONPATH, so we don't have to use propagated inputs, but that's not  possible with libraries.

Re: About conflicting entries in a profile

[Ivan Vilata i Balaguer]

Julien Lepiller (2019-05-10 08:23:22 +0200) wrote:

> >[…] What I don't get is *why* having two different versions of
> >``python-attrs`` in the profile is considered an error.  My understanding
> >was that two different packages in the profile should be able to depend on
> >different versions of the same library without problems, since they are
> >referred by its absolute path in the store so they don't conflict.  I
> >understand that I may not directly ``guix install`` two versions of the
> >same package (because the may e.g. put the same entry under
> >``$GUIX_PROFILE/bin``), but in my case ``python-attrs`` is just a
> >dependency package which doesn't show up in ``guix package -I``.
> >
> >Can anybody shed some light on the issue?  Thanks! […]
> 
> Hi,
> 
> With packages written in C for instance you're right: dependencies are
> directly embeded into binaries. With python however, we cannot embed store
> paths by default, so we use propagated-inputs instad of regular
> inputs. Propagated inputs are installed in the profile along with their
> dependant, recursively, hence the conflict.
> 
> With executable packages, we could try and wrap packages to define a
> PYTHONPATH, so we don't have to use propagated inputs, but that's not
> possible with libraries.

Aaah ok, it's clear now.  Since you mentioned them, I looked for
``propagated-inputs`` in the fine Guix manual and got the extra details from
sections "Invoking ‘guix package’" (regarding the ``--install`` option) and
"‘package’ Reference" (regarding ``propagated-inputs``).

Thank you very much!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/

Re: About conflicting entries in a profile

[Björn Höfling]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

On Fri, 10 May 2019 18:12:50 -0400
Ivan Vilata i Balaguer <ivan@selidor.net> wrote:

> Julien Lepiller (2019-05-10 08:23:22 +0200) wrote:
> 
> > >[…] What I don't get is *why* having two different versions of
> > >``python-attrs`` in the profile is considered an error.  My
> > >understanding was that two different packages in the profile
> > >should be able to depend on different versions of the same library
> > >without problems, since they are referred by its absolute path in
> > >the store so they don't conflict.  I understand that I may not
> > >directly ``guix install`` two versions of the same package
> > >(because the may e.g. put the same entry under
> > >``$GUIX_PROFILE/bin``), but in my case ``python-attrs`` is just a
> > >dependency package which doesn't show up in ``guix package -I``.
> > >
> > >Can anybody shed some light on the issue?  Thanks! […]  

Just one more note: Whenever you really NEED to somehow have two
versions of the same package installed or two packages with conflicting
propagated inputs, a solution is to install them in two different
profiles:

# Install latest guile in standard profile:
$ guix package -i guile

# Install older version into different profile:
$ guix package --profile=/home/me/test-profile -i guile@2.0

See the manual for details :-)

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]