I have a project using pipenv. I have a pipfile, and a pipfile.lock. I am deploying this repo to a remote Ubuntu server.
When running this command: pipenv install --python /usr/bin/python3.6 I get this output:
$ pipenv install --python /usr/bin/python3.6
Virtualenv already exists!
Removing existing virtualenv…
Creating a virtualenv for this project…
Using /usr/bin/python3.6 (3.6.4) to create virtualenv…
⠋Running virtualenv with interpreter /usr/bin/python3.6
Using base prefix '/usr'
New python executable in /root/.local/share/virtualenvs/me-fqgDIQ7T/bin/python3.6
Also creating executable in /root/.local/share/virtualenvs/me-fqgDIQ7T/bin/python
Installing setuptools, pip, wheel...done.
Virtualenv location: /root/.local/share/virtualenvs/me-fqgDIQ7T
Installing dependencies from Pipfile.lock (2d6b0e)…
An error occurred while installing boto==2.48.0! Will try again.
...
An error occurred while installing pynacl==1.2.1! Will try again.
WARNING: Invalid requirement, parse error at "'--extra-'"
ABORTING INSTALL... You will have to reinstall any packages that failed to install.
You may have to manually run pipenv lock when you are finished.
🐍 ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 32/45 — 00:00:08
The word "extra" does not occur anywhere in my pipfile or pipfile.lock.
I haven't been able to make any progress on this; I don't even know where to look next.
How can I further investigate this and figure out what it's trying to tell me?
Update:
There's a --verbose flag for pipenv; this lead to noticing that it was only searching in one source for each package, and since our private repo was listed first, it wasn't finding the public packages. Some googling indicates this is something weird occurring between pipenv and pip, and it's looking to me like the warning I'm seeing above is coming from pip not understanding how pipenv is telling it to look in multiple sources for the dependencies.
Either way, the situation is improved by removing our private source from the pipfile; ofc, that just means it's our packages that can't get installed...
This ended up being a versioning issue of pip between one system and another; I don't remember the exact details as to how or why the problem occurs or why this solution works, but we "solved" this problem by explicitly using pipenv version 9.0.1