all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Marius Bakke <mbakke@fastmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>, "Ricardo Wurmus" <rekado@elephly.net>
Cc: 27271@debbugs.gnu.org
Subject: bug#27271: [PATCH 0/4] Catch collisions at profile creation time
Date: Fri, 09 Jun 2017 22:32:44 +0200	[thread overview]
Message-ID: <87fuf8nbpv.fsf@fastmail.com> (raw)
In-Reply-To: <871sqtpkfo.fsf@gnu.org>

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

Ludovic Courtès <ludo@gnu.org> writes:

> Heya,
>
> Ricardo Wurmus <rekado@elephly.net> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  reply	other threads:[~2017-06-09 20:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-07  9:22 bug#27271: [PATCH 0/4] Catch collisions at profile creation time Ludovic Courtès
2017-06-07  9:25 ` bug#27271: [PATCH 1/4] profiles: Represent propagated inputs as manifest entries Ludovic Courtès
2017-06-07  9:25   ` bug#27271: [PATCH 2/4] profiles: Manifest entries keep a reference to their parent entry Ludovic Courtès
2017-06-07  9:25   ` bug#27271: [PATCH 3/4] guix package: Always upgrade packages that have propagated inputs Ludovic Courtès
2017-06-07  9:25   ` bug#27271: [PATCH 4/4] profiles: Catch and report collisions in the profile Ludovic Courtès
2017-06-09  1:42 ` bug#27271: [PATCH 0/4] Catch collisions at profile creation time Ricardo Wurmus
2017-06-09  9:41   ` Ludovic Courtès
2017-06-09 20:32     ` Marius Bakke [this message]
2017-06-10 13:39       ` bug#27271: Avoiding ‘propagated-inputs’ for Python dependencies Ludovic Courtès
2017-06-17  8:40         ` [bug#27271] " Hartmut Goebel
2017-06-17  9:00         ` Hartmut Goebel
2017-06-17  9:28     ` [bug#27271] [PATCH 0/4] Catch collisions at profile creation time Ricardo Wurmus
2017-06-17 12:30       ` Ludovic Courtès
2017-06-21  9:07         ` bug#27271: " Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fuf8nbpv.fsf@fastmail.com \
    --to=mbakke@fastmail.com \
    --cc=27271@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=rekado@elephly.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.