-
-
Notifications
You must be signed in to change notification settings - Fork 258
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
Pex fails to resolve arbitrary equality requirements when candidate package uses unnormalized version number #1949
Comments
As demonstrated in Slack, Pex can handle 2.49a1 or 2.49.0a1 - it must be Pants that is erroring here. |
Although I don't have access to boto 2.49.0a1, I do have access to pantsbuild.pants 2.14.0a0 which has the same normalization properties. I find Pex handles that completely for the entire lifecycle. Lock creation works:
Lock consumption works wether via implicit (resolve the whole lock) or explicit with version normalized or not:
|
@navneethjayendran I found a non-repro here using pantsbuild.pants since it uses a0 releases too. Can you maybe do the same and get a reproducible error that way for us to share? If not - I expect you can't given my experiment above - I think this issue is over in Pants, but that too could use a reproducible case we can both run and observe the same error. |
Ok, talking with @navneethjayendran offline, the key here is arbitrary equality (
And then consuming:
|
So the issue here is specifically dealing with |
Okay, I updated the issue with clarifying context. It seems like the right way of dealing with arbitrary equality is to supply the raw version to the specifier. If the specifier really aims to forbids textual mismatches, Pex probably should as well. |
Previously, arbitrary equality could not be used in requirements when resolving against a lockfile when the project being resolved had a PEP-440 compatible version that was normalized. Fixes pex-tool#1949
Previously, arbitrary equality could not be used in requirements when resolving against a lockfile when the project being resolved had a PEP-440 compatible version that was normalized. Fixes #1949
I'm trying to deal with a project that uses an internal fork of a package with version number 2.49.0a1. Unfortunately, this is not a canonicalized version number. The canonical form is 2.49a1. As a result, Pex fails to deal with the lockfile generated by Pants because it tries to match the canonical form 2.49a1 against the exact specifier
===2.49.0a1
.Although the best solution is probably to avoid adding package versions not in canonical form, it wouldn't hurt if Pex could handle this use case. A couple options:
The latter solution would look like this
The text was updated successfully, but these errors were encountered: