-
-
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
Failed lock on editable VCS module (with specific git reference) #5179
Labels
Type: Vendored Dependencies
This issue affects vendored dependencies within pipenv.
Comments
@mgmarino I haven't had a chance to deep dive any of this yet, but I am sure that it is caused by: sarugaku/requirementslib#310 CC @jervi |
mgmarino
added a commit
to mgmarino/requirementslib
that referenced
this issue
Jul 20, 2022
Thanks @matteius I have a fix. I'll open up an issue over there and push a PR. I'll leave this one open to track for now. |
This was referenced Jul 20, 2022
matteius
pushed a commit
to sarugaku/requirementslib
that referenced
this issue
Jul 21, 2022
* Make split ref test data driven This makes it cleaner to add additional test cases. * Add failing test case for VCS with ref and user See pypa/pipenv#5179 * Fix handling non-file-like uris with @ signs * Add news issue
matteius
added
the
Type: Vendored Dependencies
This issue affects vendored dependencies within pipenv.
label
Jul 22, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue description
We use private modules installed in editable mode per the docs that reference a specific git tag. An example entry in our
Pipfile
:As of pipenv 2022.7.4, this now fails to lock, with an error that looks like:
If you look closely, you see that the
@release/v318
is included in the clone command, which it should not be.It worked as of 2022.6.7
Here is my analysis, though I'm not entirely sure of the correct solution. It seems to involve an upstream change to requirementslib. If this is so, I'm happy to open an issue there as well.
2022.6.7
2022.7.4
The problem is possibly more apparent when you look at
Requirement.from_line
:2022.6.7
2022.7.4
Sorry for not following the normal issue format, but I hope the above analysis is still clear.
I'm happy to provide more information, and I'm also happy to open an issue (+ a PR) on the requirementslib side.
The text was updated successfully, but these errors were encountered: