-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Labels
Category: Dependency Resolution
Issue relates to dependency resolution.
Category: VCS
Relates to version control system dependencies.
Type: Bug 🐛
This issue is a bug.
Type: Regression
This issue is a regression of a previous behavior.
Comments
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
added
Type: Bug 🐛
This issue is a bug.
Category: Dependency Resolution
Issue relates to dependency resolution.
Category: VCS
Relates to version control system dependencies.
Type: Regression
This issue is a regression of a previous behavior.
labels
May 16, 2018
Oh actually, we pass |
We stumbled upon this at several places. We have to restate all dependencies whenever we use tarballs 😞 . |
techalchemy
added a commit
that referenced
this issue
Sep 3, 2018
- Fixes #2173 Signed-off-by: Dan Ryan <dan@danryan.co>
techalchemy
added a commit
that referenced
this issue
Sep 4, 2018
- Fixes #2173 Signed-off-by: Dan Ryan <dan@danryan.co>
uranusjr
pushed a commit
that referenced
this issue
Sep 5, 2018
- Fixes #2173 Signed-off-by: Dan Ryan <dan@danryan.co>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Category: Dependency Resolution
Issue relates to dependency resolution.
Category: VCS
Relates to version control system dependencies.
Type: Bug 🐛
This issue is a bug.
Type: Regression
This issue is a regression of a previous behavior.
✔️ 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.
pipenv install '-e .'
doesn't save dependencies #1024 (comment)✔️ 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'sinstall_requires
section ofsetup.py
.Pipfile
andPipfile.lock
, future use ofpipenv install
does not install the required packages as specified in that package'sinstall_requires
section ofsetup.py
.Doesn't work on my machine (I blame myself, years of accumulated cruft on this machine, homebrew, and OSX), but this may be useful:
Expected result
Having installed a local source archive file (
$ pipenv install ./SomePackage-1.0.4.tar.gz
) and checked in the resulting, updatedPipfile
andPipfile.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:
$ pipenv install && pipenv install -d
$ pipenv run pytest -vv
. This will fail withE ModuleNotFoundError: No module named 'google'
due to missing protobuf dependency from the library.$ pipenv install -v ./dependency/samplelibrary-0.0.1.tar.gz
to forcibly reinstall the local archive. Take note of the log lines:$ pipenv run pytest -vv
and see the tests now pass because the transitive dependency on protobuf has been satisfied.$ git status
and note that neitherPipfile
orPipfile.lock
has changed, which indicates that the forcible reinstall of the dependency didn't change anything.Commentary:
$reasons
can't go to a private PyPI.The text was updated successfully, but these errors were encountered: