-
Notifications
You must be signed in to change notification settings - Fork 899
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
uv
fails to install scikits.odes
on Python 3.11 due to Cython dependency resolution mismatch, works on Python 3.10 and earlier (cannot find longintrepr.h
?)
#2646
Comments
Error logs from uv with Python 3.11
|
Successful installation via pip on Python 3.11
|
I posted the logs above in separate comments since they were too long to include in one comment, being greater than 65536 characters – first time I broke that barrier ;) |
uv
fails to install scikits.odes
on Python 3.11, works on Python 3.10 and earlier (cannot find longintrepr.h
or possible Cython
dependency resolution mismatch?)uv
fails to install scikits.odes
on Python 3.11 due to Cython dependency resolution mismatch, works on Python 3.10 and earlier (cannot find longintrepr.h
?)
Scourging through the incessantly long logs: Based on https://pypi.org/project/Cython/#history we can say that |
Thanks for looking into this! I honestly think our behavior here is okay. Could you add a constraint on your side to pin |
Yes, I do too! Maybe this is a bug with
I actually don't maintain |
I think you could add a constraints file: cython<3 And then pass it when you install, like: |
Tip Scroll below to read the TL;DR ;) Okay, I spent a bit of time digging and here is what the PEP-440-compliant from packaging.version import parse
x = parse("3.0.0a8")
y = parse("3.0a7")
print(y < x) returns Here is how one can verify it: from packaging.version import parse
a = parse("3.0a7")
b = parse("3.0.0")
print(a < b) returns It was a bit confusing to get this at first, but I think maybe the Cython devs realised this mishap in the middle of getting to a stable release for A better explainer for this would be to imagine this situation, instead: from packaging.version import parse
c = parse("6.0.0a7")
d = parse("6.0a7")
print(c == d) actually returns To summariseBecause
|
Pip doesn't include prereleases when using exclusive ordered comparison, e.g. It does include prereleases when using inclusive ordered comparison, e.g. I beleive pip is following the spec here and uv is probably wrong, but the spec is open to some interpretation. I wrote about this issue here: astral-sh/packse#161, but hadn't got round to making a specific uv issue yet. |
I'm a little confused --
|
Yeah, the semantics of the specification are always at play, and the difference between |
Oh you're right, I misread things (I probably shouldn't try and investigate issues from my phone), this is one of the many areas pip isn't following the prerelease spec, I'll check later if there's an open issue or not. |
The spec is ambiguous though. Arguably they should still be excluded based on this, if you don't consider
But, IDK, I do consider this "explicitly requested by the user". |
Yes, I would consider a prerelease marker in the version to mean explicitly requested by the user, this is also generally what pypa tools and other Python packaging tools also take it to mean. |
Okay I'm starting to get (a bit) lost here – when asking the Might be worth looking at: https://discuss.python.org/t/handling-of-pre-releases-when-backtracking/40505/22 |
Being the person who opened that thread, I strongly came away with the opinion of "the spec is ambiguous" in a lot of these prerelease cases 😔, and pip has not reviewed if it is closely following it where it's not ambiguous (there's several open issues on pip side, both before this thread and after it that I've created). |
Yes, |
I'm going to close as "working as intended". |
Thanks for the speedy resolution here, @charliermarsh and @notatallshaw! I guess this is a bug to file with |
Sorry for doing a second u-turn on this conversation, I really should have waited until I had time to carefully read through everything before posting, I will try and learn from this. But I remember why I linked the packse issue now, it linked to an important comment that was in a conversation I was involved in on this: pypa/packaging#776 (comment) In particular from @dstufft
So it is intentional that packaging does not include >>> from packaging.specifiers import SpecifierSet
>>> SpecifierSet('<3.0.0a8').contains("3.0.0a7")
False
>>> SpecifierSet('<=3.0.0a8').contains("3.0.0a7")
True And this is where pip inherits it's behavior from, therefore at least according to the person who wrote the spec, uv would not be following it. |
I've created an issue on packaging side, let's see if there's any feedback there: pypa/packaging#788 |
Thanks @notatallshaw! |
This is a bug in packaging. |
FWIW I've made a PR: pypa/packaging#794 |
Description
Hi there! I'm opening this issue because I'm unable to install a package with
uv
, but the installation works withpip
– it's calledscikits.odes
. The installation instructions mention the requirement of a Fortran compiler and a SUNDIALS installation present before installing off of the source distribution available on PyPI (no wheels are available).How to reproduce
Here is a reproducer on an M-series macOS machine (compiling
scikits.odes
is much easier on Unix-like platforms such as GNU/Linux and macOS, rather than on Windows).Note
Installing SUNDIALS via Homebrew usually works, but it doesn't work at the time of writing because the formula was updated to SUNDIALS v7.0.0, which is not supported (we regularly test in CI against v6.5.0). I have provided another method of installing SUNDIALS v6.5.0 for the purpose of this MWE.
Expected behaviour
The expected behaviour would be that I can install
scikits.odes
withuv
on both Python 3.10 and Python 3.11 (or between Python 3.8–3.11 based on the provided official support for the package). I can currently installscikits.odes
withpip
on all Python versions from 3.8–3.11.Additional context
I see that #1946 faced this issue of not being able to find
longintrepr.h
earlier, I don't know if that's related – I am not used to working with Cython or Fortran codebases, but can help debug a bit withpybind11
linkage. However, I'm noticing with a deeper dive with the logs thatpip
's resolver chooses to point tocython==0.29.37
, whileuv
choosescython==3.0a7
, which might be causing the trouble?I would be happy to provide additional reproducers or logs as necessary.
xref: pybamm-team/PyBaMM#3825, aio-libs/aiohttp#6600
Specifications
uv 0.1.24 (a5cae0292 2024-03-22)
installed viapip
from PyPImacOS M-series, running Mac OS X Sonoma v14.3 (arm64)
The text was updated successfully, but these errors were encountered: