inconsistent behavior with transitive dependencies from local source archive

[StephenWithPH]

✔️ Be sure to check the existing issues (both open and closed!)
Several issues indicate ongoing, positive progress in this domain, but I don't see any other issues for this specific behavior.

• Installing a local package with pipenv install '-e .' doesn't save dependencies #1024 (comment)
• Fix install for local sdist packages #818
• Resolve dependencies of local wheels #1944

✔️ Describe the issue briefly here.

• $ pipenv install ./SomePackage-1.0.4.tar.gz works as expected, including installing required dependencies as specified in that package's install_requires section of setup.py.
• once that local package is in Pipfile and Pipfile.lock, future use of pipenv install does not install the required packages as specified in that package's install_requires section of setup.py.

⁉️ If you're on MacOS, just run the following: $ python -m pipenv.help | pbcopy
Doesn't work on my machine (I blame myself, years of accumulated cruft on this machine, homebrew, and OSX), but this may be useful:

$ pipenv --version
pipenv, version 11.10.3

$ python3 --version
Python 3.6.5

---

Expected result

Having installed a local source archive file ($ pipenv install ./SomePackage-1.0.4.tar.gz) and checked in the resulting, updated Pipfile and Pipfile.lock (and possibly the source archive itself), others should be able to clone this repo and have a fully baked pipenv-managed virtual environment by running $ pipenv install && pipenv install -d.

Actual result

Users who clone this repo and run $ pipenv install && pipenv install -d are unable to run tests and such because the pipenv-managed virtual environment is missing transitive dependencies from the local source archive.

Those users can fix themselves by running $ pipenv install ./SomePackage-1.0.4.tar.gz on their machine.

Steps to replicate

I put together a concrete example of this behavior:

• https://github.com/StephenWithPH/sample-library is the sample library which depends on some other thing (protobuf in this case). This is for reference only.
• https://github.com/StephenWithPH/sample-app is the sample application which depends on the library above and demonstrates the troubling behavior due to missing transitive dependency on protobuf.

1. clone https://github.com/StephenWithPH/sample-app.git
2. execute $ pipenv install && pipenv install -d
3. run the application's tests $ pipenv run pytest -vv. This will fail with E ModuleNotFoundError: No module named 'google' due to missing protobuf dependency from the library.
4. (optional) execute $ pipenv install -v ./dependency/samplelibrary-0.0.1.tar.gz to forcibly reinstall the local archive. Take note of the log lines:

Collecting protobuf>=3.5.2 (from samplelibrary==0.0.1)
  1 location(s) to search for versions of protobuf:
  * https://pypi.org/simple/protobuf/

5. (optional) rerun $ pipenv run pytest -vv and see the tests now pass because the transitive dependency on protobuf has been satisfied.
6. (optional) $ git status and note that neither Pipfile or Pipfile.lock has changed, which indicates that the forcible reinstall of the dependency didn't change anything.

---

Commentary:

1. pipenv is an awesome project. Thank you. Great work.
2. On the pain scale, this bug is a papercut. Once understood, the workaround is reasonable.
3. Given all of the progress with local archives, I suspect this one will get fixed naturally; this issue is meant to put it on your radar.
4. Yes, installing a local library is a hack. The (non-toy) use case is an internal team's library for other users which for $reasons can't go to a private PyPI.

[techalchemy]

Thank you for the detailed description. This is a regression of some kind that I noticed recently, and I have actually no clue how it happened but I will figure it out. Thanks for the report!

[techalchemy]

Oh actually, we pass --no-deps here and would need to skip that argument for archives I believe

[hnykda]

We stumbled upon this at several places. We have to restate all dependencies whenever we use tarballs 😞 .