[Python-ideas] Policy for altering sys.path

[Florian Bruhin]

* Thomas Güttler <guettliml at thomas-guettler.de> [2015-05-07 08:59:10 +0200]:
> 
> 
> Am 07.05.2015 um 08:48 schrieb Florian Bruhin:
> >* Thomas Güttler <guettliml at thomas-guettler.de> [2015-05-07 08:00:09 +0200]:
> >>Am 06.05.2015 um 17:07 schrieb Paul Moore:
> >>>On 6 May 2015 at 15:05, Thomas Güttler <guettliml at thomas-guettler.de> wrote:
> >>>>I am missing a policy how sys.path should be altered.
> >>>
> >>>Well, the docs say that applications can modify sys.path as needed.
> >>>Generally, applications modify sys.path in place via sys.path[:] =
> >>>whatever, but that's not mandated as far as I know.
> >>>
> >>>>We run a custom sub class of list in sys.path. We set it in sitecustomize.py
> >>>
> >>>Can you explain why?
> >>
> >>I forgot to explain the why I use a custom class. Sorry, here is the background.
> >>
> >>I want sys.path to ordered:
> >>
> >>  1. virtualenv
> >>  2. /usr/local/
> >>  3. /usr/lib
> >>
> >>We use virtualenvs with system site-packages.
> >>
> >>There are many places where sys.path gets altered.
> >>
> >>The last time we had sys.path problems I tried to write a test
> >>which checks that sys.path is the same for cron jobs and web requests.
> >>I failed. Too many places,  I could not find all the places
> >>and the conditions where sys.path got modified in a different way.
> >
> >It looks like you explained *how* you do what you do, but not *why* -
> >what problem is this solving? Why can't you just invoke the
> >virtualenv's python and let python take care of sys.path?
> 
> I want the sys.path be ordered like it, since I want that packages of the inner
> environment are tried first.
> 
> Here "inner" means "upper" in the above sys.path order.
> 
> Example: If a package is installed in the virtualenv with version 2.2 and
> in global site packages with version 1.0, then I want the interpreter to
> use the version from virtualenv.

That's already the default virtualenv behaviour:

# apt-get install python-requests
[...]
Unpacking python-requests (2.4.3-6) ...
$ ./venv/bin/pip install requests
[...]
  Downloading requests-2.7.0-py2.py3-none-any.whl (470kB): 470kB downloaded

$ python -c 'import requests; print requests.__version__'
2.4.3
$ ./venv/bin/python -c 'import requests; print requests.__version__'
2.7.0

> Does this explain the *why* enough? If not, please tell me what you want to know.

I'm mainly trying to find out why you're modifying sys.path by hand
instead of using what virtualenv already provides. There might be a
good reason for that, but to me it seems like you're reinventing the
wheel ;)

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150507/ed47ebc5/attachment.sig>