classification
Title: Windows Python 3.4.1 pyvenv doesn't work in directories with spaces.
Type: crash Stage: resolved
Components: Windows Versions: Python 3.4, Python 3.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Justin.Engel, Marcus.Smith, dstufft, eryksun, ncoghlan, paul.moore, r.david.murray, vinay.sajip
Priority: normal Keywords:

Created on 2014-06-09 14:54 by Justin.Engel, last changed 2016-08-06 10:13 by vinay.sajip. This issue is now closed.

Messages (6)
msg220098 - (view) Author: Justin Engel (Justin.Engel) Date: 2014-06-09 14:54
Venv virtual environments don't work with spaces in the path.

(env) C:\My Directory\path > pip -V
Fatal error in launcher: Unable to create process using '""C:\My Directory\path\env\Scripts\python.exe"" "C:\My Directory\path\env\Scripts\pip.exe" -V'
msg220100 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-06-09 15:30
This *can't* work on Linux (see issue 20622).  I don't know if it is possible to make it work on Windows, but I wonder: even if it is should we do so, since the point of the launcher is to make shebang lines work on Windows more or less how they do on Unix?  (The counter argument is that paths with spaces are *much* more common on Windows.)
msg220126 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2014-06-09 23:06
The py.exe launcher relies on manual quoting in the shebang line. That's the case for the shebang embedded in this pip executable. The problem is the "simple launcher" used by distlib 0.1.8. It always quotes the executable, even if it's already quoted. This is fixed in distlib 0.1.9, which should be updated in the next release of pip.

https://bitbucket.org/pypa/distlib/issue/47

As a workaround, you can use `python -m pip`.
msg228526 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2014-10-05 02:09
Note that this is also tricky to test - we *don't* currently activate the venv in the test suite, instead relying on a "-m" invocation.

However, I think this error shows that a new automated test is needed that covers the activation case, as there are some additional code paths exercised in that situation that aren't currently being adequately covered.
msg228529 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2014-10-05 02:31
Also reducing the priority back to "normal" - the docs at https://docs.python.org/3/installing/ already specifically recommend the "python -m pip" spelling because it's the most universal.

Calling "pip" directly is known to fail in a variety of situations. For example, at system level on *nix systems, it invokes the Python 2 version - you have to call "pip3" to get the Python 3 version. On Windows, if the Scripts directory isn't on PATH, calling pip directly also doesn't work.

This bug just adds another scenario to that existing list.

(I filed https://github.com/pypa/python-packaging-user-guide/issues/107 to suggest also making the "pip -> python -m pip" switch in PyPUG examples)
msg272086 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2016-08-06 10:13
I'll close this as it doesn't seem to be a Python bug.
History
Date User Action Args
2016-08-06 10:13:03vinay.sajipsetstatus: open -> closed
resolution: not a bug
messages: + msg272086

stage: test needed -> resolved
2014-10-05 02:31:34ncoghlansetpriority: critical -> normal

messages: + msg228529
2014-10-05 02:09:46ncoghlansetmessages: + msg228526
stage: needs patch -> test needed
2014-10-04 21:08:46pitrousetpriority: normal -> critical
nosy: + paul.moore, ncoghlan, dstufft, Marcus.Smith
stage: needs patch

versions: + Python 3.5
2014-06-09 23:06:32eryksunsetnosy: + eryksun
messages: + msg220126
2014-06-09 15:30:29r.david.murraysetnosy: + vinay.sajip, r.david.murray
messages: + msg220100
2014-06-09 14:54:27Justin.Engelcreate