pydantic<2.0.0 installs pydantic=2.0b3 when prereleases are allowed #1641
Comments
erdembanak
changed the title
|
How Pip behaves with exclusive operators only: Does not install pydantic prerelease: How Pip behaves with inclusive operators on June 18th 2023 (when there was only pre-releases and no final 2.0, once the final release happened inclusive operators install 2.0 final, and exclusive operators are the same): Does install pydantic prerelease: The relevant parts of the Python spec:
Some recent discussion:
IMO the Python spec leads to ambigious edge cases, I think both uv's and Pip's behavior here can be interpreted to be part of the spec. |
@erdembanak what pubgrub doc states in that page is that the semantic meaning of "<2.00" is different than its mathematic, which makes solving difficult with solvers that cannot alter the knowledge it gathers while solving depending on context. For this reason, the resolver has to take decisions that are context independent. In the case of uv, as stated in their readme https://github.com/astral-sh/uv?tab=readme-ov-file#pre-release-handling, they choose the two rules:
But if you |
|
I do not think the spec is ambiguous
(bolded capital letters from the original) |
|
Also in the spec: https://packaging.python.org/en/latest/specifications/version-specifiers/#handling-of-pre-releases
|
|
I suggest that the way to read this so that the spec is consistent is: the section about handling pre-releases is discussing the behaviour for those specifiers that only implicitly disallow pre-releases. Exclusive ordered comparisons very clearly and very explicitly always disallow pre-releases. |
zanieb
added
bug
What's ambiguous is when the resolver specifies the prerelease flag, does that implicitly mean all versions include prerelease? If it does the uv is following the spec and pip is not. If it doesn't what does it even mean to include a prerelease flag? |
see the previous comment. I believe that the section about handling pre-releases is describing an option for eg the inclusive ordered comparisons
Eg |
|
That's certainly a way to interpret the spec, but it doesn't explicitly state it, so one can also interpret how uv has implemented it. |
|
I certainly agree the spec could be clearer, but I think you have to work quite hard to justify ignoring
|
|
You only have to read the next sentence and take prerelease flag to mean that prerelease versions are included. It takes only the work of correlating two things together. |
|
In any case, I do agree your interpretation is reasonable and it's what pip does. So probably uv maintainers want to follow what pip does when what pip does makes sense? |
|
Let's not fight over this. Let's wait for what the uv team has to say. |
|
Hmm... I think my honest read of the spec is that even with That being said, I think we're unlikely to implement it (at least not soon), since (1) it breaks fundamental properties of version solving, (2) makes the solver much harder to implement and reason about, and (3) frankly, may be even more confusing for users in some cases. In other words, I just doubt it will be high-priority enough for us to support it in the near future. |
|
I suppose I'd also add (in our defense) that I wouldn't be surprised if there is no Python resolver that is fully spec compliant on pre-releases. (I can't say this definitively, I haven't looked enough.) In particular, the last clause here is very hard to satisfy, since it means you have to expand the set of candidate packages as you proceed with a resolution:
(I'm also not sure how that clause is intended to be interpreted. For example, say you have releases for Pydantic at |
This is discussed, at some length, in the Python thread I linked. I believe Poetry does attempt to follow this spec, but fails under more complicated circumstances (e.g. when backtracking on transitive dependencies), and there is an open issue on Poetry side for this. Pip does not to follow it, as linked in the various issues I posted. One of the pip maintainers characterizes the rules pip follows in the linked Python thread pretty early on. Which I believe is the approach rip is following for this. |
|
(Thanks, I swear I did read all of the pip issues you linked, but I didn’t make it through the entire Python thread yet.) |
For what it's worth I don't know any other solver that considers
it can get even more confusing than that! What if the solver goes down a path such that dependency |
|
Yeah, I'm sorry the discussion is so fragmented. Honestly I got pretty frustrated with that topic, in particular it makes it extremely difficult to try and apply some static analysis resolver optimizations I wanted to try out, because "what is the right answer" appears to both involve a lot of contextual state about what the resolver has exhausted so far and actually be pretty ambiguous in relationship to the spec. I am looking at packse, and may try and add some test cases that everyone can actually agree on, and then go from there. But I can't promise anything soon. |
|
Thanks for the comments.
I agree with this understanding. Let me tell you how I run into this issue (I wasn't just messing around). This became a problem for me when I am working with an easily reproducible requirements file:
If I allow prerelease, pydantic is installed as beta and if I don't, I can't install the packages due to azure-cli depending on a prerelease: Even without --pre marker, pip installs azure-cli; so this is not a problem in pip. I am currently using overrides file (giving pydantic==1.x.x in there) to overcome this problem (the pydantic constraint is not coming from my requirement file); but it is just a workaround and makes migrating to uv from pip a bit harder than it should be. |
|
Hmmm, the problem of "I want prereleases from one part of my requirements but not the other part of my requirements" is not supported by pip either, it just happens to be that the behavior pip has chose works out for you. Unless I'm missing something fundamental about the soundness of the behavior I'm sure one could come up with another example where it would not work for pip but it would work for uv. But pip is so pervasive that everyone checks their use case works for it and if not changes their use case. If you're interested in a workaround you can split this into multiple commands with constraints, I actually do this with pip constantly to keep my environment in sync, so this workflow will work with both uv and pip: |
|
If anyone interested, writing some additional test scenarios for this could be really helpful. |
I don't think that's right. The requirement
|
My comment about the behavior was about the choice prereleases with inclusive/exclusive operators when the prereleases flag is passed, the part of the spec you quote is highly problematic, Poetry is the only tool I'm aware of that tries to faithfully follow it but it fails to when backtracking, and I'm not even sure it's logically sound to follow when backtracking (at least using any of the satisfiability algorithms any installer currently uses). Pip certainly doesn't: pypa/pip#12469. And rip copies pip's behavior, at least for now: prefix-dev/rip#118. And I think uv copies this behavior by default also? I've not looked at the logic or tested but it seems to be able to install I know I posted a lot of links earlier and it was a bit much to expect everyone to read them, but this is how pip's current behavior is best characterized in how it "follows" that part of the spec: https://discuss.python.org/t/handling-of-pre-releases-when-backtracking/40505/4 |
|
Btw, rather than discussing the ambigious, and/or poorly implemented by everyone, spec, maybe it would make more sense to just report the usability issue that pip can install this requirement, even without the prerelease flag, and uv cannot: |
|
We can just say |
|
So far as I know everyone tries to follow the spec, of course some are more successful than others, and in different ways. All of the installers that I tried - pip / poetry / pdm - successfully install 100% agree that as a user experience this issue is best reported as |
|
So, that In the case above, we need to know that you're allowing pre-releases for In uv, the use of the pre-release marker in the direct dependency tells uv to allow pre-releases for that dependency. You can see this in the hint provided above upon failure. Unfortunately, tt seems like Azure publishes, like, everything as a pre-release? |
|
It's not entirely odd because the creation of that very spec has over time changed the packaging ecosystem in a good way. But that has meant that some of the motivating elements for compatibility with the pre PEP 440 world are no longer quite as needed. See also the post by dstufft on it: https://discuss.python.org/t/handling-of-pre-releases-when-backtracking/40505/20 So I do think that it would be in the interest of the ecosystem to consider adjusting the spec if that results in better user experience and less complex systems. |
|
As it had been said before; there are 2 discussions in here, and the original one is definitely a bug (installing 2.ob3 when user requested <2.0.0). The interesting discussion is about the second one, how to accommodate prereleases. I am still in favor of pip's behavior since the ecosystem is currently built around that. There are 2 points in my argument: I would favor prohibiting prereleases (since it is a shaky concept); but currently using uv in production means adding too many libraries in a stricted way. As a regular user, I do not want to allow prereleases; but when there are many libraries OK with that, there is not much to do for me. Btw, I would favor a course of action which changes the specs, instead of talking about it in here. |
## Summary Even when pre-releases are "allowed", per PEP 440, `pydantic<2.0.0` should _not_ include pre-releases. This PR modifies the specifier translation to treat `pydantic<2.0.0` as `pydantic<2.0.0.min0`, where `min` is an internal-only version segment that's invisible to users. Closes #1641.
|
The originating issue is fixed and will be out in the next release. (That is: |
## Summary Even when pre-releases are "allowed", per PEP 440, `pydantic<2.0.0` should _not_ include pre-releases. This PR modifies the specifier translation to treat `pydantic<2.0.0` as `pydantic<2.0.0.min0`, where `min` is an internal-only version segment that's invisible to users. Closes astral-sh#1641.
Hi @charliermarsh, I'm sorry if it came across antagonistic and if I misinterpreted what's been said. Rereading some message I know see you acknowledged the bug but still said there was no intention of fixing it soon in #1641 (comment). I just wanted to bring to your attention that if this was not addressed it sadly meant that the tool was not really a drop-in replacement of In any case, thanks for addressing it so fast finally and for the great tool! ❤️ |
Please test first. During the discussion, there was invented workaround for this problem and everything should work as expected. |
|
We tested the newest release and the behavior is def. better. I had to use |
|
Thanks -- that's intentional and documented: pre-releases need to be enabled globally or on a per-package basis. Did you try enabling pre-releases per the error message? |
|
Well, sure, with that flag it works... |
|
Also it is not easy to pass extra flags when using other tools like |
|
Also, if I understand correctly, using |
|
You're not required to use |
|
That's not ideal either, my project doesn't use |
|
What would be the issue with replicating |
|
If this default behavior shouldn't be changed at all, it would be nice to have as alternative an environment variable |
|
Yeah, we can add an environment variable. I'll take a look at it now. |
For what it's worth, I think it's reasonable to ask you to care that your package relies on unreleased dependencies. I don't expect you to agree based on your comment, but it's a very reasonable position IMO.
The core challenge is that you open the door to changing the "available versions" for a package over the course of resolution. And the spec does not cover "dependency resolution"; it's focused on evaluating a single version identifier, which is really different. Even in pip, there's an extensive discussion around what the "correct" behavior is, what the spec implies, and the bugs that pip has today in pre-release handling:
|
A workaround to this is to pass in the constraint: This solves the problem that it does not force a direct dependency on this package and solves the problem that it lets uv know upfront to allow prereleases on this package. |
|
I would also like to mention here pip's behavior is neither consistent nor intentional, the order of how pip compares prerelease requirements affects whether it will accept prereleases or not: pypa/pip#12471 So for uv to match this behavior bug for bug, uv would need to:
Otherwise uv would forever either not select prerelease when pip does or selecting prereleases when pip doesn't. |
## Summary This is useful as it tends to be "system-wide" configuration, and configuration that differs from pip. See #1641 (comment).
|
Hi Charlie, thanks a lot for your reply and time again.
Yeah, we strongly disagree here. I can give more arguments why I think this is not reasonable, I'm guessing you already thought about those and I will not say anything new to you, but just in case: I can't see any justification in why should I care at all about which dependencies my dependencies use as long as they are not direct dependencies to my project too, those being pre-releases or not. Once I chose a dependency, I decided to trust it, after all I'm executing arbitrary code from them. Why should I care if the maintainer of one of those dependencies decided the best course of action is to use a pre-release in their dependencies? How would I be better than them to judge if I might not even know what those dependencies are for or follow their development? I will just be copy&pasting dependencies to my project's dependencies. I don't see a point in doing that. This also adds a lot of maintenance cost for me, as now I need to track all transitional dependencies and litter my direct dependencies. Not only that, now how my dependencies evolve is not transparent to me anymore, as if they change those dependencies I need to update mine or risk my project to be broken or use outdated dependencies. Is really hard for me to see any advantages in the approach you are proposing.
OK, I understand I actually think it is very nice that And I guess this is the part I don't understand very well and find a bit contradictory. I could totally understand if you said "oh, yes, we are not doing the same as If I'm correct about this, which also I think is totally fine, is your tool and I'm still very grateful you open source it and are sharing it with the world, I just think you should probably not say it is a drop-in replacement for The main reason why we decided to try |
|
I can't speak for astral or their communication, but given you replied to me, I will point out by your definition of drop in replacement then new versions of pip are not a drop in replacement for old versions of pip. For example pip 20.2 can install plenty of things because of it's limited resolver compared to pip 20.3, equally the resolver behavior has changed significantly between 20.3 and 24.0, meaning different requirements will 1) Resolve or not resolve depending on what pip version you have, and 2) Produce different solutions. I think you are vastly underestimating the challenges of package resolution, from what I've seen so far uv works in all but unusual edge cases and is usually multiple times faster, that's pretty amazing and will save a lot of devs a lot of time over the long run. Anyway, I tested my workaround which solves not needing Here is the failing example But by adding the constraint with a prerelease marker then one can mark this specific package as allowing prerelease without adding it as a requirement to install: |
Trying not to repeat myself too much here. I do understand it is a hard problem, and again if the reason not to allow this case is "it's too hard", that is totally reasonable for me. But it doesn't seem to be the case here.
I also agree that it is unrealistic to pretend that uv behaves like pip in every obscure and niche corner case, but I honestly don't think this case (an indirect dependency using explicitly a pre-release in their dependencies) is an obscure corner case, it seems like a pretty reasonable case.
This for me falls into the basket of "pip has bugs too". There is also another difference, following breaking changes in pip is just advancing in time. We can say "I'm compatible with pip 24.0 or newer", but if uv diverges from pip, you are creating a fork. The problem is not leniar anymore.
Thanks, but this workaround still requires manual intervention every time a dependency starts or stops using a pre-release (if I don't "disable" accepting pre-release for that dependency after my dependencies stopped using them, then I will still accept pre-releases for it even when it is not necessary for my project, which I don't want to allow), which is an unacceptable maintenance burden for me (and it also requires passing more options to UV, which complicate integration with other tools). |
No, it's just different choices about how to resolve, and there isn't a spec on this so there's nothing to test it against being a bug or not. (FYI, I hope we can make at least some limited progress on this by sharing tests between Python installers using packse that astral have kindly published). In general anyway, there are actual bugs when a solution can't be found, or is found, but there does exist a solution, or doesn't, under the design resolver choices made.
Pip makes no guarantee of any consistency of it's resolution from one version to the next. So to say you're compatible with exact resolution choices on more than a single version would be impossible, as pip can't say that for itself. FYI, there is now a pip compatibility page in uv's documentation that explains the known differences. I will remind people, this project is less than a month publicly announced, identifying issues against a broader ecosystem takes time, and to expect it upfront before there's been a chance to encounter these issues is unreasonable.
Yeah, that's the trade off of this workaround compared to allowing all prereleaes. But solves both previously raised concerns about other solutions. And for me this is a feature, I would prefer to not have unexpected prereleases in my resolution solution unless I specifically request them. |
|
Thanks for your reply and detailed explanation. Once more I totally understand this is a very new project and again I'm super grateful that it is published and it's great. I can also understand there is only a limited amount of resources and not everything can get implemented. My point still stands that it is a shame that is not compatible with pip in what I think is a reasonable use case (but apparently you don't) where pip does the right thing. I can understand the current approach is a feature for you but it is a bug for other users (at least one, me 😀), so it would be great if you can add a pre-release resolution mode that supports it, and that will make the tool a bit more compatible with pip. Anyway I don't want to waste more of your time, I think I said everything I had to say to try to convince you there is value in supporting this user care so I'll stop now. Thanks again for the great tool and for taking the time to reply to my comments! |
Using uv 0.1.3, when trying to install pydantic<2.0 with prerelease allow, uv installs pydantic==2.0b3. According to pubgrub, 2.0b3 shouldn't be contained in the set:
Running
uv pip install --prerelease=allow "pydantic<2.0" --verboseprovides the below output:Pubgrub documentation also says that this is a difficult problem; therefore the expected behaviour of the --prerelease=allow should be documented if this is the desired output.
The text was updated successfully, but these errors were encountered: