GNU bug report logs - #34358
[PATCH] gnu: python@2.7: Honor NIX_STORE.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34358 in the body.
You can then email your comments to 34358 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Caleb Ristvedt <caleb.ristvedt <at> cune.org>
To: guix-patches <at> gnu.org, ludo <at> gnu.org
Subject: [PATCH] gnu: python <at> 2.7: Honor NIX_STORE.
Date: Wed, 06 Feb 2019 18:07:21 -0600

[Message part 1 (text/plain, inline)]

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

> Perhaps in the future you could email guix-patches <at> gnu.org for specific
> commits like this one, especially when it’s not strictly related to the
> daemon?

...

> Could you send an updated version of the patch?

Here it is!

> ./configure does not generate any patch files based on patch templates,
> and that’s on purpose.  Instead, when we need something like this, we
> handle it the way ld-wrapper.in is handled: by doing the substitution
> when creating the derivation.

"When creating the derivation" sounds like it's when the package is lowered
to a derivation, but from what I can see of ld-wrapper in (gnu packages
base) the actual substitution is done when the derivation is built. I
am curious how one would go about doing the substitution when the
package is lowered to a derivation, though. Anyway, for now I'm doing
the substitution at derivation-build-time.

> Last, the patch would need to go to ‘core-updates’ because of the number
> of rebuilds it entails.

Should I mention this somewhere?

Also, I should add that "guix lint" and indent-code.el both want changes
to gnu/packages/python.scm, but not due to changes I made. Should a
separate patch address those?

- reepca

[0001-gnu-python-2.7-Honor-NIX_STORE.patch (text/x-patch, attachment)]

Message #8 received at 34358 <at> debbugs.gnu.org (full text, mbox):

From: Sarah Morgensen <iskarian <at> mgsn.dev>
To: Caleb Ristvedt <caleb.ristvedt <at> cune.org>
Cc: ludo <at> gnu.org, 34358 <at> debbugs.gnu.org
Subject: Re: [bug#34358] [PATCH] gnu: python <at> 2.7: Honor NIX_STORE.
Date: Sat, 25 Sep 2021 19:31:19 -0700

Hello,

Caleb Ristvedt <caleb.ristvedt <at> cune.org> writes:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Perhaps in the future you could email guix-patches <at> gnu.org for specific
>> commits like this one, especially when it’s not strictly related to the
>> daemon?
>
> ...
>
>> Could you send an updated version of the patch?
>
> Here it is!
>
>> ./configure does not generate any patch files based on patch templates,
>> and that’s on purpose.  Instead, when we need something like this, we
>> handle it the way ld-wrapper.in is handled: by doing the substitution
>> when creating the derivation.
>
> "When creating the derivation" sounds like it's when the package is lowered
> to a derivation, but from what I can see of ld-wrapper in (gnu packages
> base) the actual substitution is done when the derivation is built. I
> am curious how one would go about doing the substitution when the
> package is lowered to a derivation, though. Anyway, for now I'm doing
> the substitution at derivation-build-time.
>
>> Last, the patch would need to go to ‘core-updates’ because of the number
>> of rebuilds it entails.
>
> Should I mention this somewhere?
>
> Also, I should add that "guix lint" and indent-code.el both want changes
> to gnu/packages/python.scm, but not due to changes I made. Should a
> separate patch address those?
>
> - reepca
>
>From 62e9e9a336ab5608405df8114f78c3cbb9dc3a39 Mon Sep 17 00:00:00 2001
>From: Caleb Ristvedt <caleb.ristvedt <at> cune.org>
>Date: Wed, 30 Jan 2019 17:00:32 -0600
>Subject: [PATCH] gnu: python <at> 2.7: Honor NIX_STORE.
>
>Previously various python packages would fail to work unless the store they
>were kept in was /gnu/store. This fixes that.
>
>* gnu/packages/patches/python-2.7-site-prefixes.patch.in: New file that causes
>  python <at> 2.7 to honor NIX_STORE at runtime or, if it isn't set, to use the
>  NIX_STORE available when it was built.
>
>* gnu/packages/patches/python-2.7-site-prefixes.patch: Removed.
>
>* gnu/packages/python.scm (python-2.7): generates a patch from
>  python-2.7-site-prefixes.patch.in at build-time and applies it.
>  (python-3.7): don't apply that patch.
>  (python2-minimal): inputs still need to include the patch utility and the
>  patch.
>
>* gnu/local.mk: adjust patch name since it's been suffixed with ".in".

Given that Python 2.7 is now EOL and Python 3 doesn't seem to use this
NIX_STORE patch in the first place, is this patch still relevant?

--
Sarah

Message #13 received at 34358-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Sarah Morgensen <iskarian <at> mgsn.dev>
Cc: Caleb Ristvedt <caleb.ristvedt <at> cune.org>, 34358-done <at> debbugs.gnu.org
Subject: Re: [bug#34358] [PATCH] gnu: python <at> 2.7: Honor NIX_STORE.
Date: Mon, 27 Sep 2021 18:25:54 +0200

Hi Sarah,

Sarah Morgensen <iskarian <at> mgsn.dev> skribis:

>>From 62e9e9a336ab5608405df8114f78c3cbb9dc3a39 Mon Sep 17 00:00:00 2001
>>From: Caleb Ristvedt <caleb.ristvedt <at> cune.org>
>>Date: Wed, 30 Jan 2019 17:00:32 -0600
>>Subject: [PATCH] gnu: python <at> 2.7: Honor NIX_STORE.
>>
>>Previously various python packages would fail to work unless the store they
>>were kept in was /gnu/store. This fixes that.
>>
>>* gnu/packages/patches/python-2.7-site-prefixes.patch.in: New file that causes
>>  python <at> 2.7 to honor NIX_STORE at runtime or, if it isn't set, to use the
>>  NIX_STORE available when it was built.
>>
>>* gnu/packages/patches/python-2.7-site-prefixes.patch: Removed.
>>
>>* gnu/packages/python.scm (python-2.7): generates a patch from
>>  python-2.7-site-prefixes.patch.in at build-time and applies it.
>>  (python-3.7): don't apply that patch.
>>  (python2-minimal): inputs still need to include the patch utility and the
>>  patch.
>>
>>* gnu/local.mk: adjust patch name since it's been suffixed with ".in".
>
> Given that Python 2.7 is now EOL and Python 3 doesn't seem to use this
> NIX_STORE patch in the first place, is this patch still relevant?

Let’s close it and Caleb or anyone is welcome to reopen it if there’s
interest.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.