[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About conflicting entries in a profile

From: Ivan Vilata i Balaguer
Subject: Re: About conflicting entries in a profile
Date: Fri, 10 May 2019 18:12:50 -0400
User-agent: Mutt/1.11.4 (2019-03-13)

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 --

reply via email to

[Prev in Thread] Current Thread [Next in Thread]