[PATCH] gnu: python@2.7: Honor NIX_STORE.

> Perhaps in the future you could email guix-patches@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?

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

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

> of rebuilds it entails.

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

>

>> Perhaps in the future you could email guix-patches@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@cune.org>

>Date: Wed, 30 Jan 2019 17:00:32 -0600

>Subject: [PATCH] gnu: python@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@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".

>>From 62e9e9a336ab5608405df8114f78c3cbb9dc3a39 Mon Sep 17 00:00:00 2001

>>From: Caleb Ristvedt <caleb.ristvedt@cune.org>

>>Date: Wed, 30 Jan 2019 17:00:32 -0600

>>Subject: [PATCH] gnu: python@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@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?