-
Notifications
You must be signed in to change notification settings - Fork 24
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
Remove numpy version constraint #122
Conversation
It looks like nothing in our tests or wheel builds actually needs the version pin. The wheel logs suggest numpy-1.26 is used. My sense is just to remove the restriction and deal with problems with numpy 2.0 as they arise... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm neutral on this - I would prefer to at least keep >=1.25 since it should be the case anyway and it's what we want to ensure in the wheel builds, so I don't see the harm in keeping it. We have minimum versions for other dependencies.
xref #119 |
@@ -3,6 +3,6 @@ requires = [ | |||
"setuptools", | |||
"setuptools_scm>=6.2", | |||
"jinja2>=2.10.3", | |||
"numpy>=1.25,<2" | |||
"numpy" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you should still keep the minversion pin.
"numpy" | |
"numpy>=1.25" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just spent a good 5 minutes trying to understand why this lower bound wasn't present, so I'd argue that, if nothing else, having the pin would save some dev time :-)
Any way now that numpy 2.0 is imminent, the actual requirement will soon become >=2.0
(only way to support numpy 1 and 2). It might continue to just work if we don't have the pin, however it's important information that should be communicated to downstream packagers, who, as I understand, do not necessarily rely on pip
to parse and install build time requirements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it depends what the pin here is meant to communicate. To me, it always was the minimum version that one needs to build something that works in one's current environment. For that purpose, there is no special minimum version. The >= 2.0 is needed only if the goal is to build something that will work for many environments, i.e., the wheels. But for those we have full control anyway.
I guess my logic is that we use as few constraints as are needed for our purposes -- and we do not need any.
I'm going to merge this so we can unblock #134 - I'm also removing the minimum version constraint since I basically do not see why we care for our purposes. |
Test to see if our build machinery actually needs the numpy version constraint, or whether it picks up the more recent (and thus right) version anyway.