[Python-Dev] PEP 405 (built-in virtualenv) status (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Jun 4 00:28:23 CEST 2012

On Sun, Jun 3, 2012 at 3:33 AM, Christian Tismer <tismer at stackless.com> wrote:

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.

It's mainly Py_Initialize() that triggers the magic. What may be worth exploring is a variant on that which allows embedding applications to explicitly pass in everything that would otherwise be guessed by inspecting the environment. (Some things can be forced to particular values already, but certainly not everything).

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.

Backwards compatibility constraints mean we simply can't do that. However, as noted above, it may make sense to provide more ways for embedding applications to selectively access the behaviour through the C API.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list