Pipenv install fails if path to .venv contains a '#'

[asmaier]

Issue description

On Mac OS X 10.13.4 with pipenv installed via homebrew I have

$ pipenv --version
pipenv, version 2018.7.1

I also have set the environment variable

export PIPENV_VENV_IN_PROJECT=True

When I create a folder with a hash symbol in the name like

$ mkdir usecase#2

Then entering this directory and calling pipenv will generate an error

$ cd usecase#2/
$ pipenv install numpy
Creating a virtualenv for this project...
Pipfile: /Users/<name>/tmp/usecase#2/Pipfile
Using /usr/local/Cellar/pipenv/2018.7.1/libexec/bin/python3.7 (3.7.0) to create virtualenv...
⠋Already using interpreter /usr/local/Cellar/pipenv/2018.7.1/libexec/bin/python3.7
Using real prefix '/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7'
New python executable in /Users/<name>/tmp/usecase#2/.venv/bin/python3.7
Also creating executable in /Users/<name>/tmp/usecase#2/.venv/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/<name>/tmp/usecase#2/.venv
Creating a Pipfile for this project...
Installing numpy...
⠙
Error:  An error occurred while installing numpy!
/bin/sh: /Users/<name>/tmp/usecase#2/.venv/bin/pip: /Users/<name>/tmp/usecase#2/.venv/bin/python3.7: bad interpreter: No such file or directory

Expected result

When I create a folder without a hash symbol in the name like

$ mkdir usecase2

Then entering this directory and calling pipenv will generate no error

$ cd usecase2/
$ pipenv install numpy
$ pipenv install numpy
Creating a virtualenv for this project...
Pipfile: /Users/<user>/tmp/usecase2/Pipfile
Using /usr/local/Cellar/pipenv/2018.7.1/libexec/bin/python3.7 (3.7.0) to create virtualenv...
⠋Already using interpreter /usr/local/Cellar/pipenv/2018.7.1/libexec/bin/python3.7
Using real prefix '/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7'
New python executable in /Users/<user>/tmp/usecase2/.venv/bin/python3.7
Also creating executable in /Users/<user>/tmp/usecase2/.venv/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/<user>/tmp/usecase2/.venv
Creating a Pipfile for this project...
Installing numpy...
Collecting numpy
  Downloading https://files.pythonhosted.org/packages/3a/db/5c4dab58c03a7ea2561353cb240e96198415f09d65dd63d58058e135f2f9/numpy-1.15.0-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl (24.5MB)
Installing collected packages: numpy
Successfully installed numpy-1.15.0

Adding numpy to Pipfile's [packages]...
Pipfile.lock not found, creating...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock (2cfc5e)!
Installing dependencies from Pipfile.lock (2cfc5e)...
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 1/1 — 00:00:00
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.

So it seems to me pipenv cannot handle special symbols like # in the path to .venv .

[uranusjr]

Does invoking pip directly work?

/Users/<user>/tmp/usecase#2/.venv/bin/pip install numpy

I believe it does not. This is a restriction of shebangs. There’s nothing we can do, the only option is to not create your environment in there.

[uranusjr]

If you think this should work, please raise this issue to pip. (I don’t think they would be interested in fixing this, however.)

[asmaier]

I can confirm that invoking pip directly doesn't work, either.

$ cd tmp/usecase#2/
$ pwd
/Users/<user>/tmp/usecase#2
$ pipenv shell
Launching subshell in virtual environment…
bash-3.2$  . /Users/<user>/tmp/usecase#2/.venv/bin/activate
(usecase#2)bash-3.2$ pip install pandas
bash: /Users/<user>/tmp/usecase#2/.venv/bin/pip: /Users/<user>/tmp/usecase#2/.venv/bin/python3.7: bad interpreter: No such file or directory

I found a related issue for pip, which they claimed is solved in pip 10: pypa/pip#923 So I agree, this is not a pipenv issue, but a pip issue.

[uranusjr]

In the future we could switch to use python -m pip instead, and avoid the broken scripts completely. This however would only delay the issue, until you actually want to use a command in the virtual environment. pip (distlib, actually) will need to work first.

If pip 10 did fix the issue, pipenv run python -m pip install --upgrade pip may resolve the problem.