"executable py33/bin/python3.3 is not functioning" with mac framework build #322
Comments
|
Reproduced locally - thanks for the detailed report. |
|
This gets further with the below diff but fails with Running with diff --git a/virtualenv.py b/virtualenv.py
index 2316d7c..f16dcdd 100755
--- a/virtualenv.py
+++ b/virtualenv.py
@@ -1257,6 +1257,10 @@ def install_python(home_dir, lib_dir, inc_dir, bin_dir, site_packages, clear):
mkdir(bin_dir)
py_executable = join(bin_dir, os.path.basename(sys.executable))
if 'Python.framework' in prefix:
+ # OS X framework builds cause validation to break
+ # https://github.com/pypa/virtualenv/issues/322
+ if os.environ.get('__PYVENV_LAUNCHER__'):
+ os.unsetenv('__PYVENV_LAUNCHER__')
if re.search(r'/Python(?:-32|-64)*$', py_executable):
# The name of the python executable is not quite what
# we want, rename it. |
|
I've done a pull request and I'll try to follow up with a fix for the incorrect location for install of scripts. |
Fixes pypa#322 on OS X Framework installs.
|
Notes to self this works:
|
|
Can you try with the patches on my develop branch in Pull Request #323 |
|
Yes, the changes in #323 work for me in that it creates a working virtualenv, although it doesn't solve the underlying issue that any time a non-virtualenv python3.3 process starts a virtualenv python3.3 as a subprocess this environment variable will leak through and cause the same problem. Basically, the entry points to python should not use the PYVENV_LAUNCHER variable from their environment. If Contents/MacOS/Python is an implementation detail that should only be invoked as a child of pythonw (aka $prefix/bin/python), then virtualenv should install the wrapper instead of reaching into the inner executable (it looks like this is what 3.3 venv does). If Contents/MacOS/Python is intended to be a public entry point to the interpreter, then this is really a cpython bug and the interaction between the two processes needs to be tweaked. The answer may be as simple as having cpython unset PYVENV_LAUNCHER in the environment once initialization is complete, so it won't spread to downstream processes. |
|
I'll try follow up on the subprocess chain stuff on various lists and if I need to will file another bug. |
Pip 1.1 is incompatible with Python 3.3.0, at least on OS X. See Change log in http://pypi.python.org/pypi/virtualenv and pypa/virtualenv#322.
It looks like virtualenv and python 3.3's built-in venv support interact badly in a mac framework build. Virtualenv creation fails with the message "executable not functioning". I've traced through it enough to figure out what's happening:
__PYVENV_LAUNCHER__then executes the "real" binary (Resources/Python.app/Contents/MacOS/Python). The real binary uses the launcher environment variable (if present) to determine sys.prefix__PYVENV_LAUNCHER__), it finds the right prefix.It looks like virtualenv needs to ensure that the env's python is always run with a correct (or missing)
__PYVENV_LAUNCHER__variable, and never inherits one from the environment. One way to do this would be to copy the pythonw shim into $env/bin instead of the underlying python, but I don't know what other ramifications this would have.Even though virtualenv is not needed as much since 3.3 has equivalent functionality built in, it's still important that virtualenv work with 3.3 because tools like tox do not yet support 3.3-native venvs.
My environment: OSX Mountain Lion, python 3.3rc1 installed via macports, virtualenv installed from the "develop" branch today.
The text was updated successfully, but these errors were encountered: