Skip to content
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

inconsistent behavior with transitive dependencies from local source archive #2173

StephenWithPH opened this issue May 10, 2018 · 3 comments


Copy link

@StephenWithPH StephenWithPH commented May 10, 2018

✔️ 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.

✔️ 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
  • 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

⁉️ If you're on MacOS, just run the following: $ python -m | 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:

  1. clone
  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:
  1. (optional) rerun $ pipenv run pytest -vv and see the tests now pass because the transitive dependency on protobuf has been satisfied.
  2. (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.


  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.
Copy link

@techalchemy techalchemy commented May 16, 2018

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!

Copy link

@techalchemy techalchemy commented May 16, 2018

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

Copy link

@hnykda hnykda commented Jun 18, 2018

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

@uranusjr uranusjr added this to To do in 2018.7.x Release via automation Jul 5, 2018
@uranusjr uranusjr removed this from Potential Release Blockers in 2018.06.x Release Jul 5, 2018
@uranusjr uranusjr moved this from To do to Potential release blockers in 2018.7.x Release Jul 5, 2018
@uranusjr uranusjr removed this from Potential things to work on in 2018.7.x Release Jul 30, 2018
techalchemy added a commit that referenced this issue Sep 3, 2018
- Fixes #2173

Signed-off-by: Dan Ryan <>
techalchemy added a commit that referenced this issue Sep 4, 2018
- Fixes #2173

Signed-off-by: Dan Ryan <>
uranusjr added a commit that referenced this issue Sep 5, 2018
- Fixes #2173

Signed-off-by: Dan Ryan <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants