On 21.03.12 14:35, Kristján Valur Jónsson wrote:
-Original Message-
From: Carl Meyer [mailto:c...@oddbird.net]
Sent: 19. mars 2012 19:19
To: Kristján Valur Jónsson
Cc: Python-Dev (python-dev@python.org)
Subject: Re: [Python-Dev] PEP 405 (built-in virtualenv) status
Hello Kristján,
I think there's one important (albeit odd and magical) bit of Python's current
behavior that you are missing in your blog post. All of the initial sys.path
directories are constructed relative to sys.prefix and sys.exec_prefix, and
those values in turn are determined (if PYTHONHOME is not set), by walking
up the filesystem tree from the location of the Python binary, looking for the
existence of a file at the relative path lib/pythonX.X/os.py (or Lib/os.py
on Windows). Python takes the existence of this file to mean that it's found
the standard library, and sets sys.prefix accordingly. Thus, you can achieve
reliable full isolation from any installed Python, with no need for
environment variables, simply by placing a file (it can even be empty) at that
relative location from the location of your Python binary. You will still get
some default paths added on sys.path, but they will all be relative to your
Python binary and thus presumably under your control; nothing from any
other location will be on sys.path. I doubt you will find this solution
satisfyingly elegant, but you might nonetheless find it practically useful.
Right. Thanks for explaining this. Although, it would appear that Python also
has a mechanism for detecting that it is being run from a build environment
and ignore PYTHONHOME in that case too.
Beyond that possible tweak, while I certainly wouldn't oppose any effort to
clean up / document / make-optional Python's startup sys.path-setting
behavior, I think it's mostly orthogonal to PEP 405, and I don't think it would
be helpful to expand the scope of PEP 405 to include that effort.
Well, it sounds as this pep can definitely be used as the basis for work to
completely customize the startup behaviour.
In my case, it would be desirable to be able to completely ignore any
PYTHONHOME environment variable (and any others). I'd also like to be able
to manually set up the sys.path.
Perhaps if we can set things up that one key (ignore_env) will cause
the environment variables to be ignored, and then, an empty home
key will set the sys.path to point to the directory of the .cfg file.
Presumably, this would then cause a site.py found at that place
to be executed and one could code whatever extra logic one
wants into that file.
Possibly a site key in the .cfg file would achieve the same goal, allowing
the user to call this setup file whatever he wants.
With something like this in place, the built in behaviour of python.exe
to realize that it is running from a build environment and in that case
ignore PYTHONPATH and set a special sys.path, could all be removed
from being hardcoded into being coded into some buildsite.py in the
cpython root folder.
As an old windows guy, I very much agree with Kristjan. The venv
approach is great. Windows is just a quite weird situation to handle
in some cases, and a super-simple way to get rid of *any* built-in behavior
concerning setup would be great.
The idea of moving path setup stuff into the python.exe stub
makes very much sense to me. This would make pythonxx.dll
a really useful library to be shared.
Kristjan can then provide his own custom python.exe and be assured the
python dll will not try to lurk into something unforeseen.
I think this would also be a security aspect:
The dll can be considered really safe for sandboxing if it does not even
have the ability to change the python behavior by built-in magic.
Besides that, I agree with Ethan that explicit is better than implicit,
again.
I am missing even more explicitness:
Python has IMHO too much behavior like this:
'by default, look into xxx, but if a yyy exists, behave differently'.
I don't like this, because the absense of a simple file changes the whole
system behavior.
I would do it the other way round:
As soon as you introduce the venv.cfg file, enforce its existence
completely! If that file is not there, then python exits with an error
message.
This way you can safely ensure its existence, and the file can be made
read-only and so on. A non-existent file is just a bad thing and is hard
to make
read-only ;-)
So please let's abandon the old 'if exists ...' pattern, at least this
one time.
By the explicit cfg file, the file can clearly say if there is a virtual
env or not.
Together with removing magic from the .dll, the situation at least for
windows
would greatly improve.
ciao - chris
--
Christian Tismer :^)mailto:tis...@stackless.com
tismerysoft GmbH : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key - http://pgp.uni-mainz.de
work +49 173 24 18 776 mobile
