New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

virtualenv 14.0.1 wheel creates /usr/local/bin/virtualenv-3.5 on non-Python 3.5 #851

Open
prattmic opened this Issue Jan 23, 2016 · 3 comments

Comments

Projects
None yet
2 participants
@prattmic

prattmic commented Jan 23, 2016

pip3 install virtualenv is creating /usr/local/bin/virtualenv-3.5 on my Python 3.4 installation instead of /usr/local/bin/virtualenv-3.4.

Inspecting the wheel package on PyPI, it looks like virtualenv-14.0.1.dist-info/entry_points.txt is hard-coded to create a virtualenv-3.5 binary, regardless of Python version.

I was able to work around the issue by installing with pip3 install --no-use-wheel virtualenv.

prattmic added a commit to auvsi-suas/interop that referenced this issue Jan 23, 2016

Avoid the latest virtualenv wheel
The virtualenv 14.0.1 package wheel creates a virtualenv-3.5 binary,
regardless of Python version. Since we are running Python 3.4, this
breaks later setup steps. By avoiding the wheel (and using the tar
instead), we avoid the issue.

See the virtualenv issue at pypa/virtualenv#851
(pypa/virtualenv#851).

Fixes #26

Ivoz added a commit that referenced this issue Jan 23, 2016

Remove versioned entry point
This is no longer compatible with static wheel installations, unless another hack was added to pip! :D

Solves #851
@Ivoz

This comment has been minimized.

Show comment
Hide comment
@Ivoz

Ivoz Jan 26, 2016

Member

@prattmic for now I would encourage you to only use the virtualenv script, without any version suffix. This is introduced because wheel files do not contain dynamic code to determine the installing python (they are designed not to have to run package code to be installed). Version suffixes still work correctly with pip wheels, but that is because pip itself has a hack to correct them when it recognises it's installing itself. We intend to remove the version suffixes in the future.

Member

Ivoz commented Jan 26, 2016

@prattmic for now I would encourage you to only use the virtualenv script, without any version suffix. This is introduced because wheel files do not contain dynamic code to determine the installing python (they are designed not to have to run package code to be installed). Version suffixes still work correctly with pip wheels, but that is because pip itself has a hack to correct them when it recognises it's installing itself. We intend to remove the version suffixes in the future.

@prattmic

This comment has been minimized.

Show comment
Hide comment
@prattmic

prattmic Jan 27, 2016

I currently can't use the virtualenv script without the version suffix, because I am supporting a system using both Python 2 and 3. What is the appropriate way to ensure I am using virtualenv with the correct version of Python?

For now, --no-use-wheel works fine, since it builds everything locally.

prattmic commented Jan 27, 2016

I currently can't use the virtualenv script without the version suffix, because I am supporting a system using both Python 2 and 3. What is the appropriate way to ensure I am using virtualenv with the correct version of Python?

For now, --no-use-wheel works fine, since it builds everything locally.

@Ivoz

This comment has been minimized.

Show comment
Hide comment
@Ivoz

Ivoz Jan 28, 2016

Member

virtualenv will actually support being run from either python. You just have to specify the python you wish the new virtualenv to be based off of with the -p/--python flag. For instance,

virtualenv --python=/usr/bin/python2 venv

will create a python 2 virtualenv whether the virtualenv tool was installed for python 2 or 3.

Member

Ivoz commented Jan 28, 2016

virtualenv will actually support being run from either python. You just have to specify the python you wish the new virtualenv to be based off of with the -p/--python flag. For instance,

virtualenv --python=/usr/bin/python2 venv

will create a python 2 virtualenv whether the virtualenv tool was installed for python 2 or 3.

prattmic added a commit to auvsi-suas/interop that referenced this issue Jan 31, 2016

Don't install virtualenv-3.4
The latest version (1.11.0) of the stankevich-python Puppet module will
specify the appropriate version of Python to use to the system
virtualenv install. It is no longer necessary to use a separate
virtualenv installation for Python 3.

This is the recommended path forward from pypa/virtualenv#851, as the
versioned virtualenv binaries are likely going away.

Ivoz added a commit that referenced this issue Feb 21, 2016

Remove versioned entry point
This is no longer compatible with static wheel installations, unless another hack was added to pip! :D

Solves #851
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment