From mboxrd@z Thu Jan 1 00:00:00 1970 From: iyzsong@member.fsf.org (=?utf-8?B?5a6L5paH5q2m?=) Subject: Re: PYTHONPATH issue explanation Date: Sat, 17 Mar 2018 09:41:51 +0800 Message-ID: <87lgerwk9s.fsf@member.fsf.org> References: <87371tqbyb.fsf@elephly.net> <20180223165953.GA6088@thebird.nl> <40dc2378-a039-fec8-55cd-23911f1642ab@crazy-compilers.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ex0rK-0000eZ-UF for guix-devel@gnu.org; Fri, 16 Mar 2018 21:42:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ex0rG-0002WR-1z for guix-devel@gnu.org; Fri, 16 Mar 2018 21:42:10 -0400 In-Reply-To: <40dc2378-a039-fec8-55cd-23911f1642ab@crazy-compilers.com> (Hartmut Goebel's message of "Thu, 15 Mar 2018 20:30:41 +0100") 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: Hartmut Goebel Cc: guix-devel@gnu.org Hartmut Goebel writes: Hello, > Hi, > > given the ongoing discussion around Python show that my explanation was > not good enough. I'll try to summarize and give more background. Thanks for the explanations and this one! So I have more understanding of it and ideas... > > With regard to Python, guix currently has a major issue, which my > proposals are addressing. There are other issues (like naming the > executables, the "wrapper" script", etc.) which are not addressed > here. > [...] Okay, the "major issue" is that we're using "PYTHONPATH", which will add entries into "sys.path" before builtin ones. It's semantically wrong and may (or had?) cause issues. > Part 3 of my analysis lists three solutions for this, where only number > 2 and 3 are "good choices". Option 2, "GUIX_PYTHONHOME_X_Y" can not be used in the build-system unless we make a union of python inputs, so I think we should go for 1 and optional (later) add 3 too: - "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. > Drawbacks: This might break Python appications expecting > site-packages to be below sys.prefix. We have a patch named "python-2.7-site-prefixes.patch" seems to handle this, maybe we should do it for python3 too? - Avoid any environment variable for the "profile" environment. 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 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?