Virtualenv: colon (:) support for virtualenv directory path
I'm guessing paths get screwed up since a path delimiter is usually colon. Emitting an error may help diagnose this for others:
[fedora:/tmp/a:b]$ virtualenv -v -v -v -v -v env
Creating env/lib/python2.7
This system uses lib64; symlinking lib64 to lib
Symlinking env/lib64
Symlinking Python bootstrap modules
Symlinking env/lib/python2.7/config
Symlinking env/lib/python2.7/lib-dynload
Symlinking env/lib64/python2.7/os.py
Ignoring built-in bootstrap module: posix
Symlinking env/lib64/python2.7/posixpath.py
Cannot import bootstrap module: nt
Symlinking env/lib64/python2.7/ntpath.py
Symlinking env/lib64/python2.7/genericpath.py
Symlinking env/lib64/python2.7/fnmatch.py
Symlinking env/lib64/python2.7/locale.py
Symlinking env/lib64/python2.7/encodings
Symlinking env/lib64/python2.7/codecs.py
Symlinking env/lib64/python2.7/stat.py
Symlinking env/lib64/python2.7/UserDict.py
File env/lib64/python2.7/lib-dynload/readline.so already exists
Symlinking env/lib64/python2.7/copy_reg.py
Symlinking env/lib64/python2.7/types.py
Symlinking env/lib64/python2.7/re.py
Symlinking env/lib64/python2.7/sre.py
Symlinking env/lib64/python2.7/sre_parse.py
Symlinking env/lib64/python2.7/sre_constants.py
Symlinking env/lib64/python2.7/sre_compile.py
File env/lib64/python2.7/lib-dynload/zlibmodule.so already exists
Symlinking env/lib64/python2.7/warnings.py
Symlinking env/lib64/python2.7/linecache.py
Symlinking env/lib64/python2.7/_abcoll.py
Symlinking env/lib64/python2.7/abc.py
Symlinking env/lib64/python2.7/_weakrefset.py
Creating env/lib/python2.7/site-packages
Writing env/lib64/python2.7/site.py
Writing env/lib64/python2.7/orig-prefix.txt
Writing env/lib64/python2.7/no-global-site-packages.txt
Creating parent directories for env/include
Symlinking env/include/python2.7
Creating env/bin
New python executable in env/bin/python
Changed mode of env/bin/python to 0755
Testing executable with env/bin/python -c "
import sys
prefix = sys.prefix
if sys.version_info[0] == 3:
prefix = prefix.encode('utf8')
if hasattr(sys.stdout, 'detach'):
sys.stdout = sys.stdout.detach()
elif hasattr(sys.stdout, 'buffer'):
sys.stdout = sys.stdout.buffer
sys.stdout.write(prefix)
"
ImportError: No module named site
ERROR: The executable env/bin/python is not functioning
ERROR: It thinks sys.prefix is u'/tmp/a:b' (should be u'/tmp/a:b/env')
ERROR: virtualenv is not compatible with this system or executable
[fedora:/tmp/a:b]$
[fedora:/tmp/a-b]$ virtualenv env
New python executable in env/bin/python
Installing setuptools............done.
Installing pip...............done.
[fedora:/tmp/a-b]$
[fedora:/tmp/a-b]$ python --version
Python 2.7.3
[fedora:/tmp/a-b]$ virtualenv --version
1.7.1.2
[fedora:/tmp/a-b]$
rrauenza
All 11 comments
I'm also affected by this behaviour.
~/application-2013-04-30T10:23:47$ virtualenv env
New python executable in env/bin/python
ImportError: No module named site
ERROR: The executable env/bin/python is not functioning
ERROR: It thinks sys.prefix is u'/home/deployer/application-2013-04-30T10:23:47' (should be u'/home/deployer/application-2013-04-30T10:23:47/env')
ERROR: virtualenv is not compatible with this system or executable
while it perfectly works by just removing the colons from the directory path.
~/application-2013-04-30$ virtualenv env
New python executable in env/bin/python
Please make sure you remove any previous custom paths from your /home/deployer/.pydistutils.cfg file.
Installing distribute...........................................................................................................................................................................................................................done.
Installing pip................done.
My versions are:
$ virtualenv --version
1.9.1
$ python --version
Python 2.7.2+
jvrsantacruz
on 30 Apr 2013
Reporting in with virtualenv==1.10.1 and python==2.7.3. Was trying to embed a datetime in the directory name too :).
alekstorm
on 5 Dec 2013
Chiming in to report this issue as well. I actually encountered this while trying to run a virtualenv inside chronos. The path to the sandbox has colons in it which breaks virtualenv.
srikanth-viswanathan
on 20 May 2016
After hours of debugging, thinking I had some problems with macOS default python vs homebrew python vs pyenv python, I finally discovered that virtualenv works perfect, but not when you are in a directory which has a colon in it's name!
This bug should really be fixed, as it causes very hard to debug problems.
Just for the reference, the exact error I had, so people with same stracktrace can land here from Google:
$ mkdir ~/github.com:22
$ cd !$
$ virtualenv -p python3 .  î‚ 3.3
Running virtualenv with interpreter /usr/local/bin/python3
Using base prefix '/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6'
New python executable in /home/erikw/github.com:22/bin/python3.6
Also creating executable in /home/erikw/github.com:22/bin/python
Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'
Current thread 0x00007fff9fb6f380 (most recent call first):
Installing setuptools, pip, wheel...
Complete output from command /home/erikw/github.com:22/bin/python3.6 - setuptools pip wheel:
Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'
Current thread 0x00007fff9fb6f380 (most recent call first):
----------------------------------------
...Installing setuptools, pip, wheel...done.
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/virtualenv.py", line 2349, in <module>
main()
File "/usr/local/lib/python3.6/site-packages/virtualenv.py", line 712, in main
symlink=options.symlink)
File "/usr/local/lib/python3.6/site-packages/virtualenv.py", line 953, in create_environment
download=download,
File "/usr/local/lib/python3.6/site-packages/virtualenv.py", line 904, in install_wheel
call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=SCRIPT)
File "/usr/local/lib/python3.6/site-packages/virtualenv.py", line 796, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command /home/erikw/github.com:22/bin/python3.6 - setuptools pip wheel failed with error code -6
$ cd ..
$ mv github.com:22 github.com
$ cd !$
$ virtualenv -p python3 .  î‚ 3.3
[..] # all fine, works now!
I'm using virtualenv version 15.2.0 installed with pip3 and python version 3.6.5.
Why do I have a directory with a colon in it you might ask? Because tools that create directories based on URLs, which is a not too uncommon scenario, e.g. the git clone manager ghq.
erikw
on 16 May 2018
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Just add a comment if you want to keep it open. Thank you for your contributions.
![stale[bot] picture](https://avatars3.githubusercontent.com/in/1724?v=4&s=40)
stale[bot]
on 14 Apr 2019
This is not stale.
erikw
on 14 Apr 2019
Given the shell uses the colon as a path separator ... I'm not sure this could ever be fixed. How would you add a path to PATH that includes a colon?
I think the only option is for virtualenv to error out with an explanation if the destination directory has a colon in it? Which would be somewhat simple to add and save some folks a lot of time...
rrauenza
on 20 May 2019
If we can't fix it, at least a warning/error message making debugging easier would be good.
erikw
on 20 May 2019
The path separator is platform dependent (see https://docs.python.org/3.7/library/os.html#os.pathsep). We should hard error if the path contains the path separator, but allow going ahead otherwise. A pull request achieving this would be accepted and merged.
gaborbernat
on 20 May 2019
Pull Request:
rrauenza
on 23 May 2019
Resolved via #1360 
gaborbernat
on 24 May 2019
Related issues
earthgecko
·
4Comments
LeonSpors
·
6Comments
vbabiy
·
4Comments
neildhar
·
4Comments
oconnor663
·
3Comments