Skip to content
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

Broken activation in Windows for python3 #1710

Closed
svillar opened this issue Mar 10, 2020 · 10 comments · Fixed by #1730
Closed

Broken activation in Windows for python3 #1710

svillar opened this issue Mar 10, 2020 · 10 comments · Fixed by #1730
Labels

Comments

@svillar
Copy link

svillar commented Mar 10, 2020

virtualenv activation through activate_this.py is broken in Windows for python3. Check this very simple piece of code

import os
import subprocess
import sys
from distutils.spawn import find_executable

venv = find_executable("virtualenv")
testdir = os.path.join(os.path.curdir, 'testenv')

subprocess.check_output((venv, testdir, "-p", sys.executable))

bin_path = os.path.join(testdir, "Scripts") if sys.platform in ("win32", "cygwin") else os.path.join(testdir, "bin")

path = os.path.join(bin_path, "activate_this.py")
with open(path) as f:
    exec(f.read(), {"__file__": path})

This generates a AttributeError: 'str' object has no attribute 'decode'. Taking a look at the activate_this.py code:

for lib in "..\Lib\site-packages".split(os.pathsep):
    path = os.path.realpath(os.path.join(bin_dir, lib))
    site.addsitedir(path.decode("utf-8") if "yes" else path)

it's indeed normal that we get the error because we're always calling decode() over a str. Question is where the __DECODE_PATH__ from https://github.com/pypa/virtualenv/blob/master/src/virtualenv/activation/python/activate_this.py#L28 is assigned to "yes"?

@asottile
Copy link
Contributor

asottile commented Mar 10, 2020

it comes from here (it gets replaced):

"__DECODE_PATH__": ("yes" if WIN_CPYTHON_2 else ""),

it should probably be substituted as a boolean or == "yes" as a fix

@asottile
Copy link
Contributor

asottile commented Mar 10, 2020

actually no, it looks correct as written, that'll only be truthy in cpython2.x windows (assuming the constant is correct)

@asottile
Copy link
Contributor

asottile commented Mar 10, 2020

ah, but the constant is for the host python, not the destination python

@svillar
Copy link
Author

svillar commented Mar 10, 2020

Yeah so the thing is why is it "yes" when executing the above script using python3 ?

@asottile
Copy link
Contributor

asottile commented Mar 10, 2020

in this case it's "yes" because you used a python2.x virtualenv executable to create a python3.x virtualenv -- the constant shouldn't be using the host python when templating that file is the bug

you can work around by using a python3.x virtualenv executable to create your virtualenv

@svillar
Copy link
Author

svillar commented Mar 10, 2020

well I'm using py -3 to execute it, not sure why is invoking the py2 virtualenv... my windows knowledge is pretty limitted though

@asottile
Copy link
Contributor

asottile commented Mar 10, 2020

right, it's not about the python that executes that script, but the python that was used to create the virtualenv

to be clear, there's a bug in virtualenv here -- but a workaround is to use the same python version when creating the virtualenv

@svillar
Copy link
Author

svillar commented Mar 10, 2020

Ah yeah, I've just skimmed through the PATH variable in windows and it turns out that py2.7 is listed before than py3 so find_executable() indeed locates the py2 virtualenv executable

@svillar
Copy link
Author

svillar commented Mar 10, 2020

Just for reference I think I can workaround it by doing something like

search_path = os.path.dirname(sys.executable)
find_executable('virtualenv', search_path)

and for the case of windows I guess I should concat Scripts to the search_path

@gaborbernat
Copy link
Contributor

gaborbernat commented Mar 19, 2020

Hello, a fix for this issue has been released via virtualenv 20.0.11; see https://pypi.org/project/virtualenv/20.0.11/ (https://virtualenv.pypa.io/en/latest/changelog.html#v20-0-11-2020-03-18). Please give a try and report back if your issue has not been addressed; if not, please comment here, and we'll reopen the ticket. We want to apologize for the inconvenience this has caused you and say thanks for having patience while we resolve the unexpected bugs with this new major release.
thanks

ziransun added a commit to ziransun/wpt that referenced this issue Oct 21, 2020
Tests in test_wpt.py were marked as xfail due to virtualenv
activation issue (pypa/virtualenv#1710)
This issue has now been solved.
stephenmcgruer pushed a commit to web-platform-tests/wpt that referenced this issue Oct 21, 2020
Tests in test_wpt.py were marked as xfail due to virtualenv
activation issue (pypa/virtualenv#1710)
This issue has now been solved.
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Oct 27, 2020
… in PY3, a=testonly

Automatic update from web-platform-tests
Python3: Remove xfail for wpt unit tests in PY3 (#26202)

Tests in test_wpt.py were marked as xfail due to virtualenv
activation issue (pypa/virtualenv#1710)
This issue has now been solved.
--

wpt-commits: 35faa70dcf2889231814b97c6a04e6fee8916e0e
wpt-pr: 26202
sidvishnoi pushed a commit to sidvishnoi/gecko-webmonetization that referenced this issue Oct 27, 2020
… in PY3, a=testonly

Automatic update from web-platform-tests
Python3: Remove xfail for wpt unit tests in PY3 (#26202)

Tests in test_wpt.py were marked as xfail due to virtualenv
activation issue (pypa/virtualenv#1710)
This issue has now been solved.
--

wpt-commits: 35faa70dcf2889231814b97c6a04e6fee8916e0e
wpt-pr: 26202
@pypa pypa locked and limited conversation to collaborators Jan 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants