Windows Python 3.4.1 pyvenv doesn't work in directories with spaces.

[JustinEngel]

BPO	21699
Nosy	@pfmoore, @vsajip, @ncoghlan, @bitdancer, @eryksun, @dstufft

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2016-08-06.10:13:03.276>
created_at = <Date 2014-06-09.14:54:27.218>
labels = ['invalid', 'OS-windows', 'type-crash']
title = "Windows Python 3.4.1 pyvenv doesn't work in directories with spaces."
updated_at = <Date 2016-08-06.10:13:03.274>
user = 'https://bugs.python.org/JustinEngel'

bugs.python.org fields:

activity = <Date 2016-08-06.10:13:03.274>
actor = 'vinay.sajip'
assignee = 'none'
closed = True
closed_date = <Date 2016-08-06.10:13:03.276>
closer = 'vinay.sajip'
components = ['Windows']
creation = <Date 2014-06-09.14:54:27.218>
creator = 'Justin.Engel'
dependencies = []
files = []
hgrepos = []
issue_num = 21699
keywords = []
message_count = 6.0
messages = ['220098', '220100', '220126', '228526', '228529', '272086']
nosy_count = 8.0
nosy_names = ['paul.moore', 'vinay.sajip', 'ncoghlan', 'r.david.murray', 'eryksun', 'dstufft', 'Marcus.Smith', 'Justin.Engel']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue21699'
versions = ['Python 3.4', 'Python 3.5']

[JustinEngel]

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'

[bitdancer]

This *can't* work on Linux (see bpo-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.)

[eryksun]

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.

[ncoghlan]

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.

[ncoghlan]

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 pypa/packaging.python.org#107 to suggest also making the "pip -> python -m pip" switch in PyPUG examples)

[vsajip]

I'll close this as it doesn't seem to be a Python bug.