From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: PYTHONPATH issue explanation Date: Sat, 17 Mar 2018 11:07:08 +0100 Message-ID: <87efkjxbg3.fsf@elephly.net> References: <87371tqbyb.fsf@elephly.net> <20180223165953.GA6088@thebird.nl> <40dc2378-a039-fec8-55cd-23911f1642ab@crazy-compilers.com> <87lgerwk9s.fsf@member.fsf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ex8kh-0005Xy-Mg for guix-devel@gnu.org; Sat, 17 Mar 2018 06:07:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ex8ke-0001bZ-Hl for guix-devel@gnu.org; Sat, 17 Mar 2018 06:07:51 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21075) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ex8ke-0001aW-AQ for guix-devel@gnu.org; Sat, 17 Mar 2018 06:07:48 -0400 In-reply-to: <87lgerwk9s.fsf@member.fsf.org> 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: =?utf-8?B?5a6L5paH5q2m?= Cc: guix-devel@gnu.org =E5=AE=8B=E6=96=87=E6=AD=A6 writes: > Option 2, "GUIX_PYTHONHOME_X_Y" can not be used in the build-system > unless we make a union of python inputs For texlive we create a temporary union in the build system, so this shouldn=E2=80=99t be an unsurmountable obstacle. What I don=E2=80=99t like about this solution is that PYTHONHOME can only h= old a single directory, so composing profiles (that use the same Python variant) would no longer work. I prefer the GUIX_PYTHON_X_Y_SITE_PACKAGES solution, because it is an actual search path. > - "GUIX_PYTHON_X_Y_SITE_PACKAGES" (X.Y is not a valid env identifier > in bash) is necessary for the "build" environment. > > We don't make a union of all the inputs in the "build" environment, so > a PATH (contains multiples directories) like env have to be used to > let python find all its "site-packages" from inputs. I think this might be a good solution as it is a drop-in replacement for our current use PYTHONPATH. Hartmut wrote this: > - sys.prefix and sys.exec_prefix would still point to the store, not to > the profile. This might break Python appications expecting > site-packages to be below sys.prefix. Is this an actual problem? Do you know of applications that make this assumption? If so, is this unfixable? > We have a union "profile" for all the python packages, so environment > variables can be totally avoided with the help of "venv". > > > We could avoid GUIX-PYTHONHOME[23] if we stop resolving the symlinks > > at the correct point in iteration. > > This is exactly what "venv" does! We only need to make the "profile" > a "venv" for python. For python3, a simple "pyvenv.cfg" file is > enough, for python2 I guess we have to make a union or copy files like > what "virtualenv" does. I=E2=80=99m not too hopeful about this variant, but I=E2=80=99m rather igno= rant about venvs. My main concern is about whether it will still be possible for users to create venvs from a subset of their installed packages when we generate a pyvenv.cfg by default. > I plan to implement option 1 by adding a "sitecustomize.py" (better > than modify "site.py") into the python packages, and modify > "search-path-specification" to use "GUIX_PYTHON_X_Y_SITE_PACKAGES". > > How's that sound? This sounds good to me. Thank you and thanks again, Hartmut, for laying out our options and analysing their advantages and drawbacks! Before working on this, though, I would like to have the above question answered to avoid wasting your time. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net