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

Pipenv does not follow URL-based subdependencies of a URL-based dependency #3964

Closed
selik opened this issue Sep 28, 2019 · 8 comments · Fixed by #4255
Closed

Pipenv does not follow URL-based subdependencies of a URL-based dependency #3964

selik opened this issue Sep 28, 2019 · 8 comments · Fixed by #4255
Labels

Comments

@selik
Copy link

selik commented Sep 28, 2019

I have three projects. Project A depends on B, which in turn depends on C. Each is private, hosted in GitHub. Project A in its Pipfile specifies its dependency on B via URL B = {editable = true,git = "ssh://[email protected]/selik/B.git"}. Project B specifies its dependency on C in its setup.cfg file using PEP-508 standard for URL-based dependencies C @ git+ssh://[email protected]/selik/C.git#egg=C.

Unfortunately, the real name I chose for Project C happens to collide with a project listed on PyPI. When Pipenv installs all of Project A's dependencies, I get the PyPI project C instead of my personal project C.

I can work around this by listing my personal project C as a direct dependency of project A. This is frustrating, because of the difficulty diagnosing the issue and the increased maintenance burden for anything which depends on Project B.

It looks like this feature was merged into Pip with pypa/pip#5571 in July 2018, but I'm not sure from the conversation in that thread.

@zicvic
Copy link

zicvic commented Nov 6, 2019

I have the same issue, three packages in a chain dependency fasion.. wrote about it here yesterday but I guess this is a better place, will copy paste it here

@lounis
Copy link

lounis commented Nov 6, 2019

@zicvic
Copy link

zicvic commented Nov 6, 2019

Hi @zicvic @selik
yes we have the same issue https://github.com/pypa/pipenv/issues/3976#issuecomment-549820776

Hi! Have any of you looked into where this would resolve in the code and have an idea for how to fix this? I'm a little bit tied up for the coming three weeks but after that I could take a look and see if I can come up with a solution since it doesn't seem to be anyone working on this at the moment.

@selik
Copy link
Author

selik commented Nov 7, 2019

@zicvic You might want to check out how Pip solved it in pypa/pip#5571

@vashek
Copy link

vashek commented Jan 31, 2020

I'm getting bitten by this, too. Is there any known workaround?

@davegravy
Copy link

davegravy commented Feb 1, 2020

I'm getting bitten by this, too. Is there any known workaround?

I ended up launching my own private pypi server and publishing to it so I could stop using url references

@thehesiod
Copy link

I'm having the issue with just one level, I have a pip module (fbn-googleapi) on our own pypi server, and in that module's setup.py it has the req: google-api-python-client @ git+https://github.com/thehesiod/google-api-python-client.git@thehesiod/batch-retries#egg=google-api-python-client, the Pipfile.lock that that generates is just

            "hashes": [
                "sha256:3121d55d106ef1a2756e8074239512055bd99eb44da417b3dd680f9a1385adec",
                "sha256:a8a88174f66d92aed7ebbd73744c2c319b4b1ce828e565f9ec721352d2e2fb8c"
            ],
            "version": "==1.7.11"
        },

instead of an editable link to the github repo.

I have to add google-api-python-client = {editable = true,git = "https://github.com/thehesiod/google-api-python-client.git",ref = "thehesiod/batch-retries"} to the Pipfile to make lock work correctly :(

techalchemy added a commit that referenced this issue May 17, 2020
- Fix issues parsing direct dependency URLs
- Fix vistir `rmtree` error handling automated attempts at `chmod`
  invocation which may not always be permitted
- Fix nested direct dependency parsing
- Fixes #4226
- Fixes #3964

Signed-off-by: Dan Ryan <[email protected]>
@thehesiod
Copy link

this is definitely still broken in my scenario, just tried with 2021.11.23

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants