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

Whitespace in root path of virtualenv breaks scripts #53

Open
vbabiy opened this Issue Mar 14, 2011 · 54 comments

Comments

Projects
None yet
@vbabiy
Contributor

vbabiy commented Mar 14, 2011

I'm not really sure if this is a distribute/setuptools/virtualenv but,

If I install virtualenv in

/var/lib/hudson/home/jobs/Minification WebHelpers/workspace/python/2.4

then run ./bin/easy_install:

bash: ./bin/easy_install: "/var/lib/hudson/home/jobs/Minification: bad interpreter: No such file or directory

Seems like something does not obey whitespace in path names correctly.


@rguldener

This comment has been minimized.

Show comment
Hide comment
@rguldener

rguldener Mar 20, 2012

+1, confirmed with Mac OS X 10.7.3 and Python 2.7.1

Kind of annoying, would be great to have a fix

rguldener commented Mar 20, 2012

+1, confirmed with Mac OS X 10.7.3 and Python 2.7.1

Kind of annoying, would be great to have a fix

@chaoflow

This comment has been minimized.

Show comment
Hide comment
@chaoflow

chaoflow Feb 26, 2013

We are able to create a virtualenv with spaces in the name (see #278), but easy_install and pip stumble over it later:

% virtualenv "foo bar"
New python executable in foo bar/bin/python
Installing setuptools............done.
Installing pip...............done.
% ./foo\ bar/bin/easy_install nose
zsh: ./foo bar/bin/easy_install: bad interpreter: "/tmp/cfl/foo: no such file or directory
127 % ./foo\ bar/bin/pip install nose 
zsh: ./foo bar/bin/pip: bad interpreter: "/tmp/cfl/foo: no such file or directory

chaoflow commented Feb 26, 2013

We are able to create a virtualenv with spaces in the name (see #278), but easy_install and pip stumble over it later:

% virtualenv "foo bar"
New python executable in foo bar/bin/python
Installing setuptools............done.
Installing pip...............done.
% ./foo\ bar/bin/easy_install nose
zsh: ./foo bar/bin/easy_install: bad interpreter: "/tmp/cfl/foo: no such file or directory
127 % ./foo\ bar/bin/pip install nose 
zsh: ./foo bar/bin/pip: bad interpreter: "/tmp/cfl/foo: no such file or directory
@mattvh

This comment has been minimized.

Show comment
Hide comment
@mattvh

mattvh Mar 18, 2013

I'm also here to confirm that this is an issue with OS X (10.8 here). If you edit the VIRTUAL_ENV variable and shebangs in bin you can get it to work, but a fresh env chokes on any spaces in a path. Which is a big problem for OS X, given that the boot drive is typically named "Macintosh HD," so every path starts with "/Volumes/Macintosh HD..."

The hack I'm using works as follows.

bin/activate:

VIRTUAL_ENV='/Volumes/Macintosh\ HD/path/to/my/project'

bin/pip and bin/easy_install:

#!"/Volumes/Macintosh\ HD/path/to/my/project/venv/bin/python"

Pip seems to be working after escaping the space in the path.

mattvh commented Mar 18, 2013

I'm also here to confirm that this is an issue with OS X (10.8 here). If you edit the VIRTUAL_ENV variable and shebangs in bin you can get it to work, but a fresh env chokes on any spaces in a path. Which is a big problem for OS X, given that the boot drive is typically named "Macintosh HD," so every path starts with "/Volumes/Macintosh HD..."

The hack I'm using works as follows.

bin/activate:

VIRTUAL_ENV='/Volumes/Macintosh\ HD/path/to/my/project'

bin/pip and bin/easy_install:

#!"/Volumes/Macintosh\ HD/path/to/my/project/venv/bin/python"

Pip seems to be working after escaping the space in the path.

@zakdances

This comment has been minimized.

Show comment
Hide comment
@zakdances

zakdances Aug 22, 2013

Why was this closed? It's still very much an issue. edit my mistake, it's still open

zakdances commented Aug 22, 2013

Why was this closed? It's still very much an issue. edit my mistake, it's still open

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Aug 25, 2013

Contributor

this issue still shows open.

Contributor

qwcode commented Aug 25, 2013

this issue still shows open.

@1mentat

This comment has been minimized.

Show comment
Hide comment
@1mentat

1mentat Aug 29, 2013

I was able to get around this my creating a symbolic link from my home directory to the one I was wanting to work in (that otherwise had a space in it).

1mentat commented Aug 29, 2013

I was able to get around this my creating a symbolic link from my home directory to the one I was wanting to work in (that otherwise had a space in it).

@michealbeatty

This comment has been minimized.

Show comment
Hide comment
@michealbeatty

michealbeatty Feb 4, 2014

I'm seeing this too because Mac. I get around this by manually editing the shebang line in the scripts to !#/usr/bin/env python and all works. However, as others have mentioned, this has to be done with each new env and any additional scripts installed in the env.
Seems this should be an easy fix in the code to either escape the space or use /usr/bin/env if is_darwin. However since I'm pretty much a noob at this I could be wrong.

michealbeatty commented Feb 4, 2014

I'm seeing this too because Mac. I get around this by manually editing the shebang line in the scripts to !#/usr/bin/env python and all works. However, as others have mentioned, this has to be done with each new env and any additional scripts installed in the env.
Seems this should be an easy fix in the code to either escape the space or use /usr/bin/env if is_darwin. However since I'm pretty much a noob at this I could be wrong.

@Ivoz

This comment has been minimized.

Show comment
Hide comment
@Ivoz

Ivoz Feb 4, 2014

Member

This isn't just for mac, it's basically part of the specification/behaviour of *nix systems.

You can't have spaces in the first argument of the shebang line (they will get turned into separate arguments instead), and normally there's no escaping / quoting allowed either.

http://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html

Member

Ivoz commented Feb 4, 2014

This isn't just for mac, it's basically part of the specification/behaviour of *nix systems.

You can't have spaces in the first argument of the shebang line (they will get turned into separate arguments instead), and normally there's no escaping / quoting allowed either.

http://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html

@michealbeatty

This comment has been minimized.

Show comment
Hide comment
@michealbeatty

michealbeatty Feb 4, 2014

I know, I ran into this problem with anaconda as well. t's just endemic with Mac because the drive name has the whitespace in it.

michealbeatty commented Feb 4, 2014

I know, I ran into this problem with anaconda as well. t's just endemic with Mac because the drive name has the whitespace in it.

@jashephe

This comment has been minimized.

Show comment
Hide comment
@jashephe

jashephe Dec 18, 2014

It looks like this would be corrected by #611. Has there been any review of the efficacy of that pull request?

jashephe commented Dec 18, 2014

It looks like this would be corrected by #611. Has there been any review of the efficacy of that pull request?

@diimdeep

This comment has been minimized.

Show comment
Hide comment
@diimdeep

diimdeep Feb 24, 2015

So annoying, should be fixed asap.

diimdeep commented Feb 24, 2015

So annoying, should be fixed asap.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Feb 24, 2015

Member

See the link @Ivoz posted, this is a Unix limitation. #611 might work for some Unix variants, if they support backslash escapes in a shebang line, but it's not clear which versions do (and the code just blindly does it without checking - which admittedly won't make the problem worse, but won't help either if it's not supported...)

Member

pfmoore commented Feb 24, 2015

See the link @Ivoz posted, this is a Unix limitation. #611 might work for some Unix variants, if they support backslash escapes in a shebang line, but it's not clear which versions do (and the code just blindly does it without checking - which admittedly won't make the problem worse, but won't help either if it's not supported...)

@jashephe

This comment has been minimized.

Show comment
Hide comment
@jashephe

jashephe Feb 24, 2015

It's indeed true that this is a result of the way that unix handles shebang lines, but if #611 fixes the problem for some systems and doesn't worsen the problem for others, would that still be an improvement?

jashephe commented Feb 24, 2015

It's indeed true that this is a result of the way that unix handles shebang lines, but if #611 fixes the problem for some systems and doesn't worsen the problem for others, would that still be an improvement?

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Feb 24, 2015

Member

If that's true then yes. But I can'rt comment on #611 as I'm not a Unix developer. There might be cases where it makes things worse, I just don't know. Sorry I can't be more help.

Member

pfmoore commented Feb 24, 2015

If that's true then yes. But I can'rt comment on #611 as I'm not a Unix developer. There might be cases where it makes things worse, I just don't know. Sorry I can't be more help.

@jashephe

This comment has been minimized.

Show comment
Hide comment
@jashephe

jashephe Feb 24, 2015

Fair enough. #611 probably needs to be more carefully looked at and tested for fringe cases.

jashephe commented Feb 24, 2015

Fair enough. #611 probably needs to be more carefully looked at and tested for fringe cases.

@acidjunk

This comment has been minimized.

Show comment
Hide comment
@acidjunk

acidjunk Aug 6, 2015

Even worse: on windows it breaks on the default Jenkins path with the same error:
FATAL: whitespaces are not allowed in Python interpreter's path: C:\Program Files (x86)\Jenkins\shiningpanda\jobs\c3418983\virtualenvs\d41d8cd9

acidjunk commented Aug 6, 2015

Even worse: on windows it breaks on the default Jenkins path with the same error:
FATAL: whitespaces are not allowed in Python interpreter's path: C:\Program Files (x86)\Jenkins\shiningpanda\jobs\c3418983\virtualenvs\d41d8cd9

davidbstein added a commit to davidbstein/virtualenv_decompressed_scripts that referenced this issue Oct 18, 2015

escape __VIRTUAL_ENV__ path.
Fixes issue pypa/virtualenv#53 in bash and shell by using the printf %q "shell quote" formatter, which escapes as appropriate for a given environment. Falls back to quoting some characters that universally need to be escaped. Fallback is needed because there are several printf implementations, not all of which are guaranteed to have the %q formatter (though bash always should).

davidbstein added a commit to davidbstein/virtualenv that referenced this issue Oct 18, 2015

escape string in __VIRTUAL_ENV__ path for bash
Fixes issue pypa/virtualenv#53 in bash and shell by using the printf %q "shell quote" formatter, which escapes as appropriate for a given environment. Falls back to quoting some characters that universally need to be escaped. Fallback is needed because there are several printf implementations, not all of which are guaranteed to have the %q formatter (though bash always should).

uncompressed diff here: davidbstein/virtualenv_decompressed_scripts@0bc6629
@fbidu

This comment has been minimized.

Show comment
Hide comment
@fbidu

fbidu Oct 8, 2016

I was just affected by this issue. Following the instructions I found on StackOverflow, I managed to make pip work by just setting the first line to #!/usr/bin/env python

I'm not sure, however, if that solution works for all cases... I mean, I'm not sure about which Python will be executed

fbidu commented Oct 8, 2016

I was just affected by this issue. Following the instructions I found on StackOverflow, I managed to make pip work by just setting the first line to #!/usr/bin/env python

I'm not sure, however, if that solution works for all cases... I mean, I'm not sure about which Python will be executed

@merwok

This comment has been minimized.

Show comment
Hide comment
@merwok

merwok Oct 11, 2016

Changing the shebang of installed scripts to “env python” means that they will work only in an activated virtualenv. The scripts were generated with explicit absolute paths so that they would always use the Python in the venv, and thus find the installed packages needed by the scripts.

merwok commented Oct 11, 2016

Changing the shebang of installed scripts to “env python” means that they will work only in an activated virtualenv. The scripts were generated with explicit absolute paths so that they would always use the Python in the venv, and thus find the installed packages needed by the scripts.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 11, 2016

Member

My suggestion would be that someone (probably someone affected by this issue, but at a minimum someone on a platform that has the problem and also has a way of solving it) provide a pull request implementing a check along the lines of:

  • If we have spaces in the pathname,
  • and we are on platform XXX,
  • then write the shebang line with the following escaping to handle the spaces.
  • In all other cases, fall back to the current behaviour.

Further additions could then be made by interested parties just adding extra platform checks.

Ideally, it would be nice to include a comment with a link to the documentation that confirms how platform XXX supports paths with spaces, so that future maintainers have a reference to check against. Personally, I'm not clear what fixes work and where:

  1. the discussion here suggests that double quotes work on OSX, but does that depend on the precise OSX version?
  2. In #611 escaping spaces with backslashes was used, but there was no confirmation as to what OS it was for (Linux? A specific kernel version? A specific distro?)

Note that no such platform-specific variants should use /usr/bin/env. As @merwok pointed out, that results in a change in behaviour - the shebang is deliberately written to allow running the script without activating the environment.

Adding some tests to be sure the behaviour is as expected (including the principle that it falls back when we're not on a specifically recognised platform) would be extremely useful, too, but it would also be fiddly, as it would involve monkeypatching to allow testing for platform XXX when you're not actually running on that platform.

Member

pfmoore commented Oct 11, 2016

My suggestion would be that someone (probably someone affected by this issue, but at a minimum someone on a platform that has the problem and also has a way of solving it) provide a pull request implementing a check along the lines of:

  • If we have spaces in the pathname,
  • and we are on platform XXX,
  • then write the shebang line with the following escaping to handle the spaces.
  • In all other cases, fall back to the current behaviour.

Further additions could then be made by interested parties just adding extra platform checks.

Ideally, it would be nice to include a comment with a link to the documentation that confirms how platform XXX supports paths with spaces, so that future maintainers have a reference to check against. Personally, I'm not clear what fixes work and where:

  1. the discussion here suggests that double quotes work on OSX, but does that depend on the precise OSX version?
  2. In #611 escaping spaces with backslashes was used, but there was no confirmation as to what OS it was for (Linux? A specific kernel version? A specific distro?)

Note that no such platform-specific variants should use /usr/bin/env. As @merwok pointed out, that results in a change in behaviour - the shebang is deliberately written to allow running the script without activating the environment.

Adding some tests to be sure the behaviour is as expected (including the principle that it falls back when we're not on a specifically recognised platform) would be extremely useful, too, but it would also be fiddly, as it would involve monkeypatching to allow testing for platform XXX when you're not actually running on that platform.

@fbidu

This comment has been minimized.

Show comment
Hide comment
@fbidu

fbidu Oct 14, 2016

@pfmoore As I mentioned, I was recently affected by this issue and I'm running Linux Mint 18. I have never contributed with Virtualenv but I am currently at Python Brasil and we'll have a day dedicated to sprints, I might give it a try!

fbidu commented Oct 14, 2016

@pfmoore As I mentioned, I was recently affected by this issue and I'm running Linux Mint 18. I have never contributed with Virtualenv but I am currently at Python Brasil and we'll have a day dedicated to sprints, I might give it a try!

@toejough

This comment has been minimized.

Show comment
Hide comment
@toejough

toejough Dec 16, 2016

escaping with backslashes or quotes won't work, according to https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00052.html

Experimentally, I can verify that escaping with backslashes or quotes doesn't work with OSX 10.11.6.

toejough commented Dec 16, 2016

escaping with backslashes or quotes won't work, according to https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00052.html

Experimentally, I can verify that escaping with backslashes or quotes doesn't work with OSX 10.11.6.

@yan12125

This comment has been minimized.

Show comment
Hide comment
@yan12125

yan12125 Dec 17, 2016

Contributor

virtualenv should stay away from kernel-dependent shebangs. I've checked Linux, XNU (macOS's kernel), FreeBSD, OpenBSD and NetBSD source codes. None of them can handle spaces in shebang.

Before there's a fix, don't use spaces.

Contributor

yan12125 commented Dec 17, 2016

virtualenv should stay away from kernel-dependent shebangs. I've checked Linux, XNU (macOS's kernel), FreeBSD, OpenBSD and NetBSD source codes. None of them can handle spaces in shebang.

Before there's a fix, don't use spaces.

@yan12125

This comment has been minimized.

Show comment
Hide comment
@yan12125

yan12125 Dec 27, 2016

Contributor

I submit a patch that adds a warning for Python 3's new venv, which is quite similar to virtualenv but rejected by @vsajip: http://bugs.python.org/issue28446. Indeed it's not Python's fault but an operating system's. Maybe this issue can be closed?

Contributor

yan12125 commented Dec 27, 2016

I submit a patch that adds a warning for Python 3's new venv, which is quite similar to virtualenv but rejected by @vsajip: http://bugs.python.org/issue28446. Indeed it's not Python's fault but an operating system's. Maybe this issue can be closed?

@vsajip

This comment has been minimized.

Show comment
Hide comment
@vsajip

vsajip Dec 27, 2016

Contributor

As an extra data point, note the behaviour on Windows, which seems to be as expected:


C:\Users\Vinay> "\Temp\aaa bbb\Scripts\pip" --version
pip 6.0.8 from C:\Temp\aaa bbb\lib\site-packages (python 3.4)

C:\Users\Vinay> pyzzer -i "\Temp\aaa bbb\Scripts\pip.exe"
There is a launcher.
Shebang: #!"C:\Temp\aaa bbb\Scripts\python.exe"

Archive contents:
  __main__.py

C:\Users\Vinay> "\Temp\aaa bbb\Scripts\python" -m pip install -U pip
You are using pip version 6.0.8, however version 9.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
Collecting pip from https://pypi.python.org/[...]/pip-9.0.1-py2.py3-none-any.whl#md5=297[...]
Using cached pip-9.0.1-py2.py3-none-any.whl
Installing collected packages: pip
  Found existing installation: pip 6.0.8
    Uninstalling pip-6.0.8:
      Successfully uninstalled pip-6.0.8

Successfully installed pip-9.0.1

C:\Users\Vinay> "\Temp\aaa bbb\Scripts\pip" --version
pip 9.0.1 from C:\Temp\aaa bbb\lib\site-packages (python 3.4)
Contributor

vsajip commented Dec 27, 2016

As an extra data point, note the behaviour on Windows, which seems to be as expected:


C:\Users\Vinay> "\Temp\aaa bbb\Scripts\pip" --version
pip 6.0.8 from C:\Temp\aaa bbb\lib\site-packages (python 3.4)

C:\Users\Vinay> pyzzer -i "\Temp\aaa bbb\Scripts\pip.exe"
There is a launcher.
Shebang: #!"C:\Temp\aaa bbb\Scripts\python.exe"

Archive contents:
  __main__.py

C:\Users\Vinay> "\Temp\aaa bbb\Scripts\python" -m pip install -U pip
You are using pip version 6.0.8, however version 9.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
Collecting pip from https://pypi.python.org/[...]/pip-9.0.1-py2.py3-none-any.whl#md5=297[...]
Using cached pip-9.0.1-py2.py3-none-any.whl
Installing collected packages: pip
  Found existing installation: pip 6.0.8
    Uninstalling pip-6.0.8:
      Successfully uninstalled pip-6.0.8

Successfully installed pip-9.0.1

C:\Users\Vinay> "\Temp\aaa bbb\Scripts\pip" --version
pip 9.0.1 from C:\Temp\aaa bbb\lib\site-packages (python 3.4)
@yan12125

This comment has been minimized.

Show comment
Hide comment
@yan12125

yan12125 Dec 29, 2016

Contributor

Yep virtualenv scripts on Windows work as distlib defines its own shebang protocol in PC/launcher.c. Maybe POSIX can have something similar - a user space shebang parser instead of unreliable kernels.

Contributor

yan12125 commented Dec 29, 2016

Yep virtualenv scripts on Windows work as distlib defines its own shebang protocol in PC/launcher.c. Maybe POSIX can have something similar - a user space shebang parser instead of unreliable kernels.

@vsajip

This comment has been minimized.

Show comment
Hide comment
@vsajip

vsajip Dec 29, 2016

Contributor

a user space shebang parser instead of unreliable kernels

I'm not sure why Bash can't do this (for example) - I don't think it's a kernel-space thing.

Contributor

vsajip commented Dec 29, 2016

a user space shebang parser instead of unreliable kernels

I'm not sure why Bash can't do this (for example) - I don't think it's a kernel-space thing.

@yan12125

This comment has been minimized.

Show comment
Hide comment
@yan12125

yan12125 Dec 29, 2016

Contributor

Shebangs are handled in kernel space because it should be usable outside shells.

Technical details:
On UNIX-like systems (Linux, Mac, *BSD, ...), a new program is created via fork() and exec(). exec() is similar to CreateProcess() on Windows, which runs a new program. On UNIX-like systems, exec() eventually calls the system call execve(). The latter function is implemented in kernels, so shebang parsing is done in kernels.
It can't be implemented in C libraries, either, or static linked programs or programs that uses system calls directly (via int 80 or sysenter, etc.) won't work.

Contributor

yan12125 commented Dec 29, 2016

Shebangs are handled in kernel space because it should be usable outside shells.

Technical details:
On UNIX-like systems (Linux, Mac, *BSD, ...), a new program is created via fork() and exec(). exec() is similar to CreateProcess() on Windows, which runs a new program. On UNIX-like systems, exec() eventually calls the system call execve(). The latter function is implemented in kernels, so shebang parsing is done in kernels.
It can't be implemented in C libraries, either, or static linked programs or programs that uses system calls directly (via int 80 or sysenter, etc.) won't work.

@fbidu

This comment has been minimized.

Show comment
Hide comment
@fbidu

fbidu Dec 29, 2016

Maybe we should just forbid the creation of a virtual environment with spaces in the path. It won't work as expected anyway

fbidu commented Dec 29, 2016

Maybe we should just forbid the creation of a virtual environment with spaces in the path. It won't work as expected anyway

@vsajip

This comment has been minimized.

Show comment
Hide comment
@vsajip

vsajip Dec 29, 2016

Contributor

Shebangs are handled in kernel space because it should be usable outside shells

Yes, but couldn't a shell do the parsing itself if the system call returned ENOEXEC? I realise it might be a can of worms ...

Interesting tidbit - the kernel functionality on Linux appears to have been written by long-time Python committer Martin von Löwis :-)

This page was also an interesting read: http://www.in-ulm.de/~mascheck/various/shebang/

Contributor

vsajip commented Dec 29, 2016

Shebangs are handled in kernel space because it should be usable outside shells

Yes, but couldn't a shell do the parsing itself if the system call returned ENOEXEC? I realise it might be a can of worms ...

Interesting tidbit - the kernel functionality on Linux appears to have been written by long-time Python committer Martin von Löwis :-)

This page was also an interesting read: http://www.in-ulm.de/~mascheck/various/shebang/

@yan12125

This comment has been minimized.

Show comment
Hide comment
@yan12125

yan12125 Dec 29, 2016

Contributor

Yes, but couldn't a shell do the parsing itself if the system call returned ENOEXEC?

IMO different semantics between shells and the underlying kernel would bring lots of confusion to users as well as developers. Currently at least bash and zsh do parsing when execve() fails, but only for better error reporting, not providing a fallback.

Interesting tidbit - the kernel functionality on Linux appears to have been written by long-time Python committer Martin von Löwis :-)

Interesting! I didn't notice that :) Also thanks for the extra material. While reading the kernel source code is the fastest way, such documents is still helpful.

About @fbidu's idea:

Maybe we should just forbid the creation of a virtual environment with spaces in the path. It won't work as expected anyway

Creating virtual environments with fragile paths are useful for testing corner cases in path handling. In this example it demonstrates how kernels are broken. My idea is adding warnings instead of forbidding, just like the patch I've posted to http://bugs.python.org/issue28446

Contributor

yan12125 commented Dec 29, 2016

Yes, but couldn't a shell do the parsing itself if the system call returned ENOEXEC?

IMO different semantics between shells and the underlying kernel would bring lots of confusion to users as well as developers. Currently at least bash and zsh do parsing when execve() fails, but only for better error reporting, not providing a fallback.

Interesting tidbit - the kernel functionality on Linux appears to have been written by long-time Python committer Martin von Löwis :-)

Interesting! I didn't notice that :) Also thanks for the extra material. While reading the kernel source code is the fastest way, such documents is still helpful.

About @fbidu's idea:

Maybe we should just forbid the creation of a virtual environment with spaces in the path. It won't work as expected anyway

Creating virtual environments with fragile paths are useful for testing corner cases in path handling. In this example it demonstrates how kernels are broken. My idea is adding warnings instead of forbidding, just like the patch I've posted to http://bugs.python.org/issue28446

@JDLH

This comment has been minimized.

Show comment
Hide comment
@JDLH

JDLH Feb 25, 2017

I think #994 "Pip fails with space in virtualenv path" is a duplicate of this issue.

I want to repeat the comment from #997 (comment), "virtualenv are broken with fragile kernel shebang parsing." And in that spirit, #1014 "Not compatible with a directory having emojis in its path" is another example of virtualenv being broken by fragile kernel shebang parsing. I'll bet the problem occurs with any non-ASCII characters in the path, in fact.

Maybe we should collect all three aspects of fragile kernel shebang parsing into one issue, so that we can be sure that one fix can address spaces, length, and non-ASCII characters in the virtualenv path? I nominate this issue, because it's the oldest.

JDLH commented Feb 25, 2017

I think #994 "Pip fails with space in virtualenv path" is a duplicate of this issue.

I want to repeat the comment from #997 (comment), "virtualenv are broken with fragile kernel shebang parsing." And in that spirit, #1014 "Not compatible with a directory having emojis in its path" is another example of virtualenv being broken by fragile kernel shebang parsing. I'll bet the problem occurs with any non-ASCII characters in the path, in fact.

Maybe we should collect all three aspects of fragile kernel shebang parsing into one issue, so that we can be sure that one fix can address spaces, length, and non-ASCII characters in the virtualenv path? I nominate this issue, because it's the oldest.

@JDLH

This comment has been minimized.

Show comment
Hide comment
@JDLH

JDLH Feb 25, 2017

While we work on a fix, I think it would be good for virtualenv to print a warning when asked to create an environment in a path which a) has spaces, b) is too long, or c) has non-ASCII characters. A sentence in some documentation would help also.

JDLH commented Feb 25, 2017

While we work on a fix, I think it would be good for virtualenv to print a warning when asked to create an environment in a path which a) has spaces, b) is too long, or c) has non-ASCII characters. A sentence in some documentation would help also.

@yan12125

This comment has been minimized.

Show comment
Hide comment
@yan12125

yan12125 Feb 25, 2017

Contributor

I'll bet the problem occurs with any non-ASCII characters in the path, in fact.

I believe the reason for #1014 is in virtualenv rather than the kernel. I have a patch that fixes a quite similar problem at #900.

Contributor

yan12125 commented Feb 25, 2017

I'll bet the problem occurs with any non-ASCII characters in the path, in fact.

I believe the reason for #1014 is in virtualenv rather than the kernel. I have a patch that fixes a quite similar problem at #900.

@ahoebeke

This comment has been minimized.

Show comment
Hide comment
@ahoebeke

ahoebeke Mar 11, 2017

Hi all,
This is super annoying and such a huge waste of time due to something seemingly so simple (simple cause at least).

How about renaming (when possible), or using links (creating a directory such as /virtualenvs/python3.5 without space, then letting this be a soft link to the original directory?)

ahoebeke commented Mar 11, 2017

Hi all,
This is super annoying and such a huge waste of time due to something seemingly so simple (simple cause at least).

How about renaming (when possible), or using links (creating a directory such as /virtualenvs/python3.5 without space, then letting this be a soft link to the original directory?)

@yan12125

This comment has been minimized.

Show comment
Hide comment
@yan12125

yan12125 Mar 11, 2017

Contributor

creating a directory such as /virtualenvs/python3.5 without space

Another project virtualenvwrapper has done something quite similar.

something seemingly so simple (simple cause at least).

Neither are simple. The cause is related to kernel parsing codes and a workaround requires user space shebang handling.

Contributor

yan12125 commented Mar 11, 2017

creating a directory such as /virtualenvs/python3.5 without space

Another project virtualenvwrapper has done something quite similar.

something seemingly so simple (simple cause at least).

Neither are simple. The cause is related to kernel parsing codes and a workaround requires user space shebang handling.

@fultonm

This comment has been minimized.

Show comment
Hide comment
@fultonm

fultonm May 16, 2017

It's still an issue 6 years later?

fultonm commented May 16, 2017

It's still an issue 6 years later?

@JDLH

This comment has been minimized.

Show comment
Hide comment
@JDLH

JDLH May 16, 2017

This issue tripped me up 2 weeks ago. Yes, it's still an issue.

JDLH commented May 16, 2017

This issue tripped me up 2 weeks ago. Yes, it's still an issue.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore May 16, 2017

Member

Note that as it's a Unix issue rather than a virtualenv issue, it's unlikely that it'll get "fixed" unless the Unix kernel limitation is removed...

Member

pfmoore commented May 16, 2017

Note that as it's a Unix issue rather than a virtualenv issue, it's unlikely that it'll get "fixed" unless the Unix kernel limitation is removed...

@JDLH

This comment has been minimized.

Show comment
Hide comment
@JDLH

JDLH May 17, 2017

The first virtualenv bug is that virtualenv chose to implement shell-executable files by using a certain Unix kernel feature, despite that feature having limitations that routinely cause problems for virtualenv user. Virtualenv could fix this by using a different mechanism for shell-executable files. The second virtualenv bug is to have no documentation of how users should use virtualenv in order to work around the first bug (create a virtualenv only on short paths with ASCII-only characters and no whitespace). The third virtualenv bug is that it has no mechanism which detects cases where the user chooses a virtualenv path which will trigger the first bug, and print a helpful warning message. There's plenty that virtualenv contributers could do to improve the situation.

JDLH commented May 17, 2017

The first virtualenv bug is that virtualenv chose to implement shell-executable files by using a certain Unix kernel feature, despite that feature having limitations that routinely cause problems for virtualenv user. Virtualenv could fix this by using a different mechanism for shell-executable files. The second virtualenv bug is to have no documentation of how users should use virtualenv in order to work around the first bug (create a virtualenv only on short paths with ASCII-only characters and no whitespace). The third virtualenv bug is that it has no mechanism which detects cases where the user chooses a virtualenv path which will trigger the first bug, and print a helpful warning message. There's plenty that virtualenv contributers could do to improve the situation.

@yan12125

This comment has been minimized.

Show comment
Hide comment
@yan12125

yan12125 May 17, 2017

Contributor

@JDLH About your first "bug": it's not handled by virtualenv but distlib, and there's an implementation at https://bitbucket.org/pypa/distlib/pull-requests/31/. I hope I could have time to study the internals of distlib and reply to Vinay Sajip's comments properly but unfortunately I don't.

Contributor

yan12125 commented May 17, 2017

@JDLH About your first "bug": it's not handled by virtualenv but distlib, and there's an implementation at https://bitbucket.org/pypa/distlib/pull-requests/31/. I hope I could have time to study the internals of distlib and reply to Vinay Sajip's comments properly but unfortunately I don't.

@vsajip

This comment has been minimized.

Show comment
Hide comment
@vsajip

vsajip May 17, 2017

Contributor

The first virtualenv bug is that virtualenv chose to implement shell-executable files by using a certain Unix kernel feature

@JDLH This is not specific to virtualenv - all Unix script files (i.e. files with shebang lines) use this kernel feature - and there is no compelling reason for virtualenv (or anything else) to reinvent a completely new method of dispatching scripts, when the existing mechanism is so widely used and well understood. If you wrote a script by hand which had spaces in the interpreter path (no virtualenv involved) it would exhibit the same problem.

There's plenty that virtualenv contributers could do to improve the situation.

There are probably many calls on contributors' time. This issue affects the relatively small number of cases where long paths/paths with spaces are used. Perhaps some of those users who are affected could help the contributors to help them by proposing a patch which would help with the detection and warning messages? Just an idea.

@yan12125 distlib allows one to specify the executable in the shebang line however one wants. The kernel limitation on whitespace / long lines perhaps won't ever be fixed by Linux developers because of backward compatibility. One could just provide a custom string for the shebang executable (incorporating a generalised equivalent to the Mozilla script hack) and distlib should write it into the script, so one can experiment with it just as a distlib user (hence with no need to look at the internals, AFAICT).

Contributor

vsajip commented May 17, 2017

The first virtualenv bug is that virtualenv chose to implement shell-executable files by using a certain Unix kernel feature

@JDLH This is not specific to virtualenv - all Unix script files (i.e. files with shebang lines) use this kernel feature - and there is no compelling reason for virtualenv (or anything else) to reinvent a completely new method of dispatching scripts, when the existing mechanism is so widely used and well understood. If you wrote a script by hand which had spaces in the interpreter path (no virtualenv involved) it would exhibit the same problem.

There's plenty that virtualenv contributers could do to improve the situation.

There are probably many calls on contributors' time. This issue affects the relatively small number of cases where long paths/paths with spaces are used. Perhaps some of those users who are affected could help the contributors to help them by proposing a patch which would help with the detection and warning messages? Just an idea.

@yan12125 distlib allows one to specify the executable in the shebang line however one wants. The kernel limitation on whitespace / long lines perhaps won't ever be fixed by Linux developers because of backward compatibility. One could just provide a custom string for the shebang executable (incorporating a generalised equivalent to the Mozilla script hack) and distlib should write it into the script, so one can experiment with it just as a distlib user (hence with no need to look at the internals, AFAICT).

@JDLH

This comment has been minimized.

Show comment
Hide comment
@JDLH

JDLH May 17, 2017

This is not specific to virtualenv

@vsajip This is a true statement — other software uses the same shebang mechanism which virtualenv chose — but it misses the point of this issue. There is nothing about the value provided by virtualenv that demands it use the shebang. virtualenv could use a different mechanism, but it chose the shebang, and thus virtualenv really does inherit the shebang's limitation.

there is no compelling reason for virtualenv (or anything else) to reinvent a completely new method of dispatching scripts

I think what you are saying is that the problems experienced by the people who have encountered this issue over the years are not "compelling". I think the reason why so many people find and comment on this issue over the years is that they do find the problems "compelling". I certainly do.

Perhaps some of those users who are affected could help the contributors to help them by proposing a patch which would help with the detection and warning messages? Just an idea.

I chose the word "contributors" to include both the stalwarts who do most of the work on virtualenv, and the visitors like me who find this problem compelling enough to work on a reducing its impact. It's fair to say that we who find the problem compelling should contribute a patch.

It would be helpful if the stalwarts who know virtualenv well could suggest promising approaches. If I wanted to insert a warning message for the user who types virtualenv ~/my\ long\ path\ with\ spaces, where should that code best reside? Are there non-obvious constraints on such a patch, which the stalwarts could share, to remove an obstacle from the visitor working on their first contribution? Do the stalwarts have some historical objection to accepting such a patch? (I mean, I can't be the first person who thought of adding a warning message. There has to be a reason it hasn't happened yet.)

JDLH commented May 17, 2017

This is not specific to virtualenv

@vsajip This is a true statement — other software uses the same shebang mechanism which virtualenv chose — but it misses the point of this issue. There is nothing about the value provided by virtualenv that demands it use the shebang. virtualenv could use a different mechanism, but it chose the shebang, and thus virtualenv really does inherit the shebang's limitation.

there is no compelling reason for virtualenv (or anything else) to reinvent a completely new method of dispatching scripts

I think what you are saying is that the problems experienced by the people who have encountered this issue over the years are not "compelling". I think the reason why so many people find and comment on this issue over the years is that they do find the problems "compelling". I certainly do.

Perhaps some of those users who are affected could help the contributors to help them by proposing a patch which would help with the detection and warning messages? Just an idea.

I chose the word "contributors" to include both the stalwarts who do most of the work on virtualenv, and the visitors like me who find this problem compelling enough to work on a reducing its impact. It's fair to say that we who find the problem compelling should contribute a patch.

It would be helpful if the stalwarts who know virtualenv well could suggest promising approaches. If I wanted to insert a warning message for the user who types virtualenv ~/my\ long\ path\ with\ spaces, where should that code best reside? Are there non-obvious constraints on such a patch, which the stalwarts could share, to remove an obstacle from the visitor working on their first contribution? Do the stalwarts have some historical objection to accepting such a patch? (I mean, I can't be the first person who thought of adding a warning message. There has to be a reason it hasn't happened yet.)

@revolter

This comment has been minimized.

Show comment
Hide comment
@revolter

revolter May 17, 2017

There is one well-known path that contains spaces and cannot be modified: /Users/iulian/Library/Mobile Documents/com~apple~CloudDocs. So anyone who wants to keep some scripts managed with virtualenv in iCloud bumps into this problem.

revolter commented May 17, 2017

There is one well-known path that contains spaces and cannot be modified: /Users/iulian/Library/Mobile Documents/com~apple~CloudDocs. So anyone who wants to keep some scripts managed with virtualenv in iCloud bumps into this problem.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore May 17, 2017

Member

It would be helpful if the stalwarts who know virtualenv well could suggest promising approaches.

Well, if we knew any, we would probably not have left this issue unresolved for so long, given the amount of criticism we seem to get for doing so :-(

If I wanted to insert a warning message for the user who types virtualenv ~/my\ long\ path\ with\ spaces, where should that code best reside?

You could start by looking at the argument parsing code, adding a check once the path has been determined.

Are there non-obvious constraints on such a patch, which the stalwarts could share, to remove an obstacle from the visitor working on their first contribution?

They can mostly be found by searching the issue list here for the various comments made on this and other issues over the years, but to start with, you need to not reject paths when they will work - and that means working out what limitations the OS imposes. These vary drastically between systems. Windows allows spaces and long filenames, some Unix systems allow spaces, some need paths with spaces to be quoted, some have very short length limits (32 characters?) some longer, ... Many limitations aren't well documented, and very few contributors have access to sufficient systems to be able to test all the possibilities enough to supplement the available docs.

Do the stalwarts have some historical objection to accepting such a patch?

No, other than "don't assume it's as simple as you think at first glance, and don't ignore all of the various (sometimes pretty obscure) systems we have to support".

If someone does want to take a stab at this - and they should be aware that it's not something that I'd personally recommend as a "first contribution" - then they should start by reading all of the history available in the various issues (some linked from this one, others probably not, some probably on the pip tracker and maybe even the distlib or setuptools trackers) and summarise in a new PR the constraints imposed by various OSes. Propose that as a documentation patch that states "unless these conditions are met, the shebang headers used by virtualenv will not work as expected, and so virtualenv does not support creating environments in directories that don't match the stated conditions". The PR can include a code change to warn if the documented conditions are not met, or can propose this as future work (as from what I recall, it's pretty hard to introspect the system details precisely enough to know what limits apply - consider "Ubuntu with a patched kernel"...). Personally, I'd be OK with a warning that only flagged known cases where things would fail, and was silent if it wasn't sure. But I'd also be fine with a docs-only patch at this stage.

You'd then need to get reviews of your patch from people with access to the systems you cover - as noted, the core devs can't really help here because none of us use (for example) FreeBSD, or OpenBSD, or Solaris, or ...

You could also just do a partial job, and create a PR that added docs and a warning only for (say) OSX. I don't know if that would stop the complaints about this issue (I don't have a feel for what systems this comes up on most frequently) but maybe it would be sufficient. Possibly one of the core devs who uses OSX would be OK with merging that.

Does that help?

Member

pfmoore commented May 17, 2017

It would be helpful if the stalwarts who know virtualenv well could suggest promising approaches.

Well, if we knew any, we would probably not have left this issue unresolved for so long, given the amount of criticism we seem to get for doing so :-(

If I wanted to insert a warning message for the user who types virtualenv ~/my\ long\ path\ with\ spaces, where should that code best reside?

You could start by looking at the argument parsing code, adding a check once the path has been determined.

Are there non-obvious constraints on such a patch, which the stalwarts could share, to remove an obstacle from the visitor working on their first contribution?

They can mostly be found by searching the issue list here for the various comments made on this and other issues over the years, but to start with, you need to not reject paths when they will work - and that means working out what limitations the OS imposes. These vary drastically between systems. Windows allows spaces and long filenames, some Unix systems allow spaces, some need paths with spaces to be quoted, some have very short length limits (32 characters?) some longer, ... Many limitations aren't well documented, and very few contributors have access to sufficient systems to be able to test all the possibilities enough to supplement the available docs.

Do the stalwarts have some historical objection to accepting such a patch?

No, other than "don't assume it's as simple as you think at first glance, and don't ignore all of the various (sometimes pretty obscure) systems we have to support".

If someone does want to take a stab at this - and they should be aware that it's not something that I'd personally recommend as a "first contribution" - then they should start by reading all of the history available in the various issues (some linked from this one, others probably not, some probably on the pip tracker and maybe even the distlib or setuptools trackers) and summarise in a new PR the constraints imposed by various OSes. Propose that as a documentation patch that states "unless these conditions are met, the shebang headers used by virtualenv will not work as expected, and so virtualenv does not support creating environments in directories that don't match the stated conditions". The PR can include a code change to warn if the documented conditions are not met, or can propose this as future work (as from what I recall, it's pretty hard to introspect the system details precisely enough to know what limits apply - consider "Ubuntu with a patched kernel"...). Personally, I'd be OK with a warning that only flagged known cases where things would fail, and was silent if it wasn't sure. But I'd also be fine with a docs-only patch at this stage.

You'd then need to get reviews of your patch from people with access to the systems you cover - as noted, the core devs can't really help here because none of us use (for example) FreeBSD, or OpenBSD, or Solaris, or ...

You could also just do a partial job, and create a PR that added docs and a warning only for (say) OSX. I don't know if that would stop the complaints about this issue (I don't have a feel for what systems this comes up on most frequently) but maybe it would be sufficient. Possibly one of the core devs who uses OSX would be OK with merging that.

Does that help?

@raxod502

This comment has been minimized.

Show comment
Hide comment
@raxod502

raxod502 May 18, 2017

Perhaps I don't understand something, but couldn't this issue be solved by having (for example) bin/pip contain

#!/bin/sh
"/my/long path/with spaces/pythonx.y" "/path/to/my project/with spaces/venv/bin/real-pip" "$@"

and then moving the current pip script to real-pip? I don't see why we have to use the shebang directly.

raxod502 commented May 18, 2017

Perhaps I don't understand something, but couldn't this issue be solved by having (for example) bin/pip contain

#!/bin/sh
"/my/long path/with spaces/pythonx.y" "/path/to/my project/with spaces/venv/bin/real-pip" "$@"

and then moving the current pip script to real-pip? I don't see why we have to use the shebang directly.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore May 18, 2017

Member

@raxod502 I assume you're aware this wouldn't work on Windows. Also, I think the "normal" incantation needed on the second line is more complex than the one you give (although I don't know why, personally). You can probably find the proper approach via a web search. With your approach, what would happen for paths with " or $ characters in them?

Assuming you can address these sorts of issue, I guess the next step would be for you to submit a PR (as per the comments above) and we can debate specifics on that. You'd need to get at least one of the virtualenv core committers who works on Unix involved - as a Windows user I wouldn't be willing to merge a Unix-specific PR like this myself.

Member

pfmoore commented May 18, 2017

@raxod502 I assume you're aware this wouldn't work on Windows. Also, I think the "normal" incantation needed on the second line is more complex than the one you give (although I don't know why, personally). You can probably find the proper approach via a web search. With your approach, what would happen for paths with " or $ characters in them?

Assuming you can address these sorts of issue, I guess the next step would be for you to submit a PR (as per the comments above) and we can debate specifics on that. You'd need to get at least one of the virtualenv core committers who works on Unix involved - as a Windows user I wouldn't be willing to merge a Unix-specific PR like this myself.

@gst

This comment has been minimized.

Show comment
Hide comment
@gst

gst May 24, 2017

@pfmoore
proposed solution by @raxod502 could also work on windows with a .bat script file, afaik ?

gst commented May 24, 2017

@pfmoore
proposed solution by @raxod502 could also work on windows with a .bat script file, afaik ?

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore May 24, 2017

Member

@gst Short answer, no. Long answer is at http://paul-moores-notes.readthedocs.io/en/latest/wrappers.html There have been many discussions on this point over the years, and every time someone has come up with a solution other than an exe wrapper, it's had problems.

In this case, please remember this problem does not exist on Windows. So there's absolutely no reason to change anything in the Windows environment - any change must be restricted to Unix only.

Member

pfmoore commented May 24, 2017

@gst Short answer, no. Long answer is at http://paul-moores-notes.readthedocs.io/en/latest/wrappers.html There have been many discussions on this point over the years, and every time someone has come up with a solution other than an exe wrapper, it's had problems.

In this case, please remember this problem does not exist on Windows. So there's absolutely no reason to change anything in the Windows environment - any change must be restricted to Unix only.

@gst

This comment has been minimized.

Show comment
Hide comment
@gst

gst May 25, 2017

thx for good answer :)

other than an exe wrapper, it's had problems.

personally I can live with that (if I had to).

gst commented May 25, 2017

thx for good answer :)

other than an exe wrapper, it's had problems.

personally I can live with that (if I had to).

@vsajip

This comment has been minimized.

Show comment
Hide comment
@vsajip

vsajip May 28, 2017

Contributor

I've updated distlib to handle long paths and paths with spaces. I didn't use Harald Nordgren's patch directly (it had some problems - e.g. no tests) but the approach is the same - using '/bin/sh' as the executable. pip / virtualenv maintainers might want to test after locally vendoring the current version of the distlib repository.

Contributor

vsajip commented May 28, 2017

I've updated distlib to handle long paths and paths with spaces. I didn't use Harald Nordgren's patch directly (it had some problems - e.g. no tests) but the approach is the same - using '/bin/sh' as the executable. pip / virtualenv maintainers might want to test after locally vendoring the current version of the distlib repository.

@pradyunsg

This comment has been minimized.

Show comment
Hide comment
@pradyunsg

pradyunsg Nov 10, 2017

Member

The development version of pip now does vendor this newer version of distlib, which means pip now handles spaces in directory names just fine.

As I understand it, once the next release of pip and a virtualenv release are made, this issue will get fixed -- any new virtualenv created will support spaces in path, as will binaries installed by pip (except possibly in some quirky cases like setuptools' wrappers that are not directly installed by pip).

Member

pradyunsg commented Nov 10, 2017

The development version of pip now does vendor this newer version of distlib, which means pip now handles spaces in directory names just fine.

As I understand it, once the next release of pip and a virtualenv release are made, this issue will get fixed -- any new virtualenv created will support spaces in path, as will binaries installed by pip (except possibly in some quirky cases like setuptools' wrappers that are not directly installed by pip).

@smurf0

This comment has been minimized.

Show comment
Hide comment
@smurf0

smurf0 Dec 8, 2017

I've just started using gvfs to mount samba shares in user space and find virtualenv/pip etc scuppered on account of punction in the mount paths generated by gvfs.

There are no spaces in the paths, but plenty of other things to bring virtualenv/pip etc to their knees trying to run in a dir like

/run/user/1000/gvfs/smb-share:server=bolt,share=eng/projects/msp/mrfbus/land

As far as I can see there is no option currently in gvfs to prevent punctuation in the paths of it's generated mount points. My only workaround is to never create a virtualenv on a gvfs mount , which seems a little sad

smurf0 commented Dec 8, 2017

I've just started using gvfs to mount samba shares in user space and find virtualenv/pip etc scuppered on account of punction in the mount paths generated by gvfs.

There are no spaces in the paths, but plenty of other things to bring virtualenv/pip etc to their knees trying to run in a dir like

/run/user/1000/gvfs/smb-share:server=bolt,share=eng/projects/msp/mrfbus/land

As far as I can see there is no option currently in gvfs to prevent punctuation in the paths of it's generated mount points. My only workaround is to never create a virtualenv on a gvfs mount , which seems a little sad

@raxod502

This comment has been minimized.

Show comment
Hide comment
@raxod502

raxod502 Dec 8, 2017

@pradyunsg Is there any timeline for the next pip release? The last one was over a year ago, and it seems kinda dumb to wait so long for this really simple fix to show up in virtualenv.

raxod502 commented Dec 8, 2017

@pradyunsg Is there any timeline for the next pip release? The last one was over a year ago, and it seems kinda dumb to wait so long for this really simple fix to show up in virtualenv.

@pradyunsg

This comment has been minimized.

Show comment
Hide comment
@pradyunsg

pradyunsg Dec 8, 2017

Member

Hi @raxod502!

Yeah, we want to get it out soon. The thing is we're short on developer time to get PEP 518 out the door, which is something we want to do. It might just happen that there's a pip 10 without PEP 518 but again, it depends on finding the time to get the plan settled on that.

Member

pradyunsg commented Dec 8, 2017

Hi @raxod502!

Yeah, we want to get it out soon. The thing is we're short on developer time to get PEP 518 out the door, which is something we want to do. It might just happen that there's a pip 10 without PEP 518 but again, it depends on finding the time to get the plan settled on that.

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