guix-patches
[Top][All Lists]
Advanced

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

bug#27271: [PATCH 0/4] Catch collisions at profile creation time


From: Marius Bakke
Subject: bug#27271: [PATCH 0/4] Catch collisions at profile creation time
Date: Fri, 09 Jun 2017 22:32:44 +0200
User-agent: Notmuch/0.24.2 (https://notmuchmail.org) Emacs/25.2.1 (x86_64-unknown-linux-gnu)

Ludovic Courtès <address@hidden> writes:

> Heya,
>
> Ricardo Wurmus <address@hidden> skribis:
>
>>> These patches allow us to catch problematic collisions when computing
>>> a profile derivation.  As we know, the profile builder often spits out
>>> a number of warnings about collisions but that is not very useful because
>>> users cannot distinguish the problematic cases from the harmless cases
>>> (an example of a harmless case is when GDB and Binutils provide an
>>> almost-identical .info file twice).
>>
>> This is very good!  Thanks for implementing it!
>>
>>> An open question is whether there are commonly used combinations of
>>> packages that trigger conflicts.  I haven’t had any problems with my
>>> profile (with 234 packages) nor with my GuixSD config, but I encourage
>>> you to test it on your profile!
>>
>> We often see this at the MDC because some people don’t use manifests and
>> I may have upgraded the shared Guix instance between invocations of
>> “guix package”.  This happens particularly often with numpy because
>> that’s propagated quite often.  (I’d *love* to get rid of propagated
>> inputs in Python!  They are so annoying!)
>
> Perhaps we could modify ‘sys.path’ from the top of ‘__init__.py’ file to
> get something similar to RUNPATH.  I’m not sure if there are any
> downsides or gotchas.  Thoughts?

Python actually has a native mechanism for setting up package-specific
search paths: https://docs.python.org/3/library/site.html

In short, it looks for a file "package.pth" where additional search
paths can be specified (other sys.path manipulations are allowed too).

I asked Hartmut about this during the python-build-system refactoring,
and the counter-argument was that if package A and B depends on
different versions of package C, odd failures could occur. I'm not
convinced propagation sidesteps this problem, however:

https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00856.html

It would be good to try it out.

Attachment: signature.asc
Description: PGP signature


reply via email to

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