What is the correct way to install local file-backed distributions with pipenv?

Trying to install a local file-backed distribution on Heroku. Previously, using standard pip/requirements.txt Heroku detected setup.py and installed the local package automatically. Now, using pipenv, with the same structure, it does not automatically detect setup.py for some reason. Per the Heroku docs I need to provide a path to the local distribution to the requirements.txt. Or, add -e . to provoke pip to run python setup.py develop What is the pipenv equivalent?

Apologies if requiring local packages is addressed in the docs, but I didn’t see it…

Python 3.6.2 pipenv, version 8.2.7 Heroku

Package installation using normal setup.py install command works fine both locally and on Heroku. pipenv run setup.py install heroku python setup.py install

Top-level directory structure looks like this:

├── Pipfile ├── Procfile ├── README.md ├── bin ├── resources ├── runtime.txt ├── setup.py ├── src │   └── pblc │   ├── init.py │   ├── main.py ├── (package files) └── test

Tried: pipenv install path/to/setup.py which in my case is just pipenv install setup.py Expected it to add the path to the Pipfile as a requirement

Got the following traceback:

(backend_app-Nxg7F8OH) katestohr:backend_app kate$ pipenv install setup.py
Installing setup.py…
Collecting setup.py

Error:  An error occurred while installing setup.py!
  Could not find a version that satisfies the requirement setup.py (from versions: )
No matching distribution found for setup.py

Any guidance on the best way to require a local package in Pipfile…?

[techalchemy]

No it doesn’t. The bug we have is currently to do with traversing local relative directories specifically so if you don’t make any reference to a directory (i.e. there is no / in your install command) you should be ok. For example, pipenv install requests.whl would work, but pipenv install wheels/requests.whl would not, nor would pipenv install ../wheels/requests.whl, nor would even pipenv install ./requests.whl assuming all were valid paths. This will be fixed in the near future, I should have time to dig into it this weekend.

[kstohr]

Roger that… thank you. Saw the ‘file://’ solution suggested above and in #939, but since the absolute path would be different in production not sure that would work in my use case… Thanks again.