From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hartmut Goebel Subject: Re: PYTHONPATH issue analysis - part 3 Date: Thu, 15 Mar 2018 20:48:19 +0100 Message-ID: <268e4e91-e323-0359-35bf-5bf9a5e5c618@crazy-compilers.com> References: <87371tqbyb.fsf@elephly.net> <20180223165953.GA6088@thebird.nl> <871sgn1xhf.fsf@gnu.org> <20180313214431.GA15654@thebird.nl> <3713e2d0-600f-d624-03b6-19096643c876@crazy-compilers.com> <20180314074941.GA18245@thebird.nl> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7A615AA9F28D9939E71DBEE1" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:32897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ewYrT-0006Si-9Y for guix-devel@gnu.org; Thu, 15 Mar 2018 15:48:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ewYrQ-0004rU-6k for guix-devel@gnu.org; Thu, 15 Mar 2018 15:48:27 -0400 In-Reply-To: <20180314074941.GA18245@thebird.nl> Content-Language: en-US List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pjotr Prins Cc: guix-devel@gnu.org This is a multi-part message in MIME format. --------------7A615AA9F28D9939E71DBEE1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Am 14.03.2018 um 08:49 schrieb Pjotr Prins: > On Tue, Mar 13, 2018 at 11:02:03PM +0100, Hartmut Goebel wrote: >> Am 13.03.2018 um 22:44 schrieb Pjotr Prins: >>> Another problem is that it does not cover special cases where, for >>> example you compile Python with SSL and without. You don't want them >>> to share user installed libs. >> Upstream does not handle this case, so I do not see a need to handle >> this in guix. If we find a way, this would be find. But prior to solving >> the optional we should solve the compulsory :-) > https://github.com/python/cpython/blob/master/configure#L1543 > > and there are many other options which define the behaviour of the > interpreter. We don't use them in GNU Guix, but it does not mean we > should not think about it/allow it. Now I understand you point: If there are two variants of e.g Python 3.5 available, but there is only one GUIX-PYTHONHOME-3.5 variable, this will intermix the environments again. You are right! Adding the hash would indeed be a good solution :-) -- Regards Hartmut Goebel | Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | --------------7A615AA9F28D9939E71DBEE1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Am 14.03.2018 um 08:49 schrieb Pjotr Prins:
On Tue, Mar 13, 2018 at 11:02:03PM +0100, Hartmut Goebel wrote:

Am 13.03.2018 um 22:44 schrieb Pjotr Prins:

Another problem is that it does not cover special cases where, for
example you compile Python with SSL and without. You don't want them
to share user installed libs.

Upstream does not handle this case, so I do not see a need to handle
this in guix. If we find a way, this would be find. But prior to solving
the optional we should solve the compulsory :-)

  https://github.com/python/cpython/blob/master/configure#L1543

and there are many other options which define the behaviour of the
interpreter. We don't use them in GNU Guix, but it does not mean we
should not think about it/allow it.

Now I understand you point: If there are two variants of e.g Python 3.5 available, but there is only one GUIX-PYTHONHOME-3.5 variable, this will intermix the environments again.

You are right!

Adding the hash would indeed be a good solution :-)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |
--------------7A615AA9F28D9939E71DBEE1--