-
-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
MAINT: version bounds before 1.8.0rc1 #15191
MAINT: version bounds before 1.8.0rc1 #15191
Conversation
3f2d0c4
to
f6a35a7
Compare
pyproject.toml
Outdated
@@ -9,11 +9,11 @@ | |||
|
|||
[build-system] | |||
requires = [ | |||
"wheel", | |||
"wheel<0.38.0", | |||
"setuptools<58.5", |
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'll check if we can bump this to <60.0.0
by removing the pins in master.
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 actually not sure if we should bump to 59.5
or 60.0
. I think the former is safer, because it's not yet clear to me in which release setuptools
will re-enable its vendored distutils
copy.
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.
For the record: this got changed to 60.0
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.
Overall looks good, a few minor things. And I still need to deal with setuptools
and oldest-supported-numpy
changes syncing check. I'll work on that now.
Maybe you can cherry-pick commit b568120 into this PR as well? |
* attempt to add upper version bounds before 1.8.0rc1
Synced change from oldest-supported-numpy
f6a35a7
to
3ac0f72
Compare
I did that, and the other stuff suggested I think (currently with the newer |
Okay, let's leave that for now. It doesn't matter for |
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.
LGTM, thanks Tyler.
ok, |
64-bit Python 3.8 windows failure for wheel build--I'll try restarting, but pasting below as well (this kind of multiprocessing thing seems familiar lately, and we did add something related in MacPython/scipy-wheels#144 to
|
ok, we lucked out, restarting worked |
* I never get this quite right, but here is the first draft of the version bounds for `1.9.0rc1`, which is probably even more complicated with some of the meson stuff until I'm used to that * for reference, last branching we did this: scipygh-15191 * I think if NumPy releases before us we can, in theory, squeeze another +1 version if we're careful to address warnings (I think we actually ignored some though..)
* I never get this quite right, but here is the first draft of the version bounds for `1.9.0rc1`, which is probably even more complicated with some of the meson stuff until I'm used to that * for reference, last branching we did this: scipygh-15191 * I think if NumPy releases before us we can, in theory, squeeze another +1 version if we're careful to address warnings (I think we actually ignored some though..)
For reference, last branching we did this: gh-15191
before 1.8.0rc1
@rgommers I usually depend on you to find my mistakes on the version bounds stuff.
For reference, for
maintenance/1.7.x
last time we did this for the bounds: #14145