Installing bad package name removes version specifiers from Pipfile causing lock failures #5865
Comments
|
Is it because you are missing a version specifier on pydantic? Nothing else really stands out to me about it: v2023.8.21...v2023.8.23 |
|
Does the new version check for the "version" tag in pipfile? Somehow the previous version is able to achieve locking without this constraint. When I add The error seems misleading as pipenv should be iterating the version of pydantic and not the private-repo |
|
I was under the assumption in the refactor away from requirementslib that if the pipfile entry is a string, its likely a version specifier (but learned it could be a vcs string) and then I thought if it was a dictionary there would always be a version key for a named requirement. I just checked out to While on the one hand we want to be backwards compatible, I think this is a case where it is better if we move forward with requiring the version specifier and not inferring you mean star specifier. I think then the enhancement would be based around Pipfile validation before entering into a lock phase. I think that was something you were interested in looking at one point @oz123 ? |
|
It seems like we should reinclude Cerberus in our vendor. That pipfile without version specificier should trigger an exception. |
I'd be in favor of consider it vs a vanilla data-class solution that does some validations -- its such an old library that I think if we can avoid it we will be better off. |
|
Re-adding Cerberus is only temporary until we do a rewrite with dataclasses. |
|
I have a couple of doubts here.... I am finding some odd behaviour Installing a package that does not exist??The command have failed as expected, but what does Automatically removes the version specifiers in pipfileThis is my pipfile initially Lets say I made some typo and wrote the following The output is same as the first one, installation have failed, BUT now pipfile is updated to following pydantic have lost its It was this change that caused me to face the issue I raised, and just adding the version in pydantic helped to lock new package that was being installed |
|
@edwinjosegeorge Are you saying trying to install a non existent package that fails is removing the version specifier for an unrelated Pipfile entry? 🤔 |
|
Yep. There is no such package
|
matteius
changed the title
|
That is really bizarre -- I just confirmed what you are saying -- the interesting thing is the version specifiers were left alone in dev group, but in the packages it was stripped from the dictionary. |
|
I think any failed install causes this behavior, not just nonexistent packages, FYI. I'm running into the problem like this: > pipenv --version
pipenv, version 2023.8.23
> pipenv install invenio-app-rdm[opensearch2,postgresql]==11.0.4 # succeeds, version in Pipfile
> pipenv install invenio-saml # fails with a build error on my MacOS
> grep invenio-app-rdm Pipfile
invenio-app-rdm = {extras = ["postgresql", "opensearch2"] } |
matteius
added
the
Priority: High
|
I believe this has been fixed in |
|
I can't reproduce it anymore in my tests, trying > pipenv --version
pipenv, version 2024.3.0
> pipenv install requests==2.32.2
> pipenv install cchardet==2.1.7 # this fails for me
> grep requests Pipfile
requests = "==2.32.2" |
Issue description
Unable to lock using
pipenv==2023.8.23whilepipenv==2023.8.21can. The latest version reports mismatch in sub-dependency but upon inspection, the resolution is actually possible.Expected result
Lock to succeed
Actual result
Steps to replicate
My Pipfile
remove the old lock file
Create new lock
This command fails for
pipenv==2023.8.23but succeeds forpipenv=2023.8.21as the later installspydantic==1.10.12The text was updated successfully, but these errors were encountered: