Skip to content
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

Merged

Conversation

tylerjereddy
Copy link
Contributor

  • attempt to add upper version bounds
    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

@tylerjereddy tylerjereddy added the maintenance Items related to regular maintenance tasks label Dec 9, 2021
setup.py Outdated Show resolved Hide resolved
@rgommers rgommers added this to the 1.8.0 milestone Dec 10, 2021
pyproject.toml Outdated
@@ -9,11 +9,11 @@

[build-system]
requires = [
"wheel",
"wheel<0.38.0",
"setuptools<58.5",
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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

Copy link
Member

@rgommers rgommers left a 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.

pyproject.toml Outdated Show resolved Hide resolved
scipy/__init__.py Show resolved Hide resolved
scipy/__init__.py Outdated Show resolved Hide resolved
setup.py Outdated Show resolved Hide resolved
@rgommers
Copy link
Member

Maybe you can cherry-pick commit b568120 into this PR as well?

tylerjereddy and others added 2 commits December 10, 2021 13:35
* attempt to add upper version bounds
before 1.8.0rc1
Synced change from oldest-supported-numpy
@tylerjereddy
Copy link
Contributor Author

Maybe you can cherry-pick commit b568120 into this PR as well?

I did that, and the other stuff suggested I think (currently with the newer setuptools which is perhaps undecided, mostly because I didn't see the second comment fast enough).

@rgommers
Copy link
Member

I did that, and the other stuff suggested I think (currently with the newer setuptools which is perhaps undecided, mostly because I didn't see the second comment fast enough).

Okay, let's leave that for now. It doesn't matter for rc1, so it's easy to change after. Actually that setuptools release will come out well before 1.8.0 final.

Copy link
Member

@rgommers rgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks Tyler.

@rgommers rgommers merged commit da15f83 into scipy:maintenance/1.8.x Dec 10, 2021
@tylerjereddy tylerjereddy deleted the treddy_180_version_pins branch December 10, 2021 21:55
@tylerjereddy
Copy link
Contributor Author

ok, 1.8.0rc1 wheel builds are running

@tylerjereddy
Copy link
Contributor Author

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 run_scipy_tests.py):

________________ TestDifferentialEvolutionSolver.test_parallel ________________
[gw1] win32 -- Python 3.8.0 C:\Python38-x64\python.exe
C:\Python38-x64\lib\site-packages\scipy\optimize\tests\test__differential_evolution.py:615: in test_parallel
    solver.solve()
        bounds     = [(0.0, 2.0), (0.0, 2.0)]
        p          = <multiprocessing.pool.Pool state=TERMINATE pool_size=2>
        self       = <scipy.optimize.tests.test__differential_evolution.TestDifferentialEvolutionSolver object at 0x00000173AC674EB0>
        solver     = <scipy.optimize._differentialevolution.DifferentialEvolutionSolver object at 0x00000173AC632A30>
C:\Python38-x64\lib\multiprocessing\pool.py:733: in __exit__
    self.terminate()
        exc_tb     = None
        exc_type   = None
        exc_val    = None
        self       = <multiprocessing.pool.Pool state=TERMINATE pool_size=2>
C:\Python38-x64\lib\multiprocessing\pool.py:656: in terminate
    self._terminate()
        self       = <multiprocessing.pool.Pool state=TERMINATE pool_size=2>
C:\Python38-x64\lib\multiprocessing\util.py:201: in __call__
    res = self._callback(*self._args, **self._kwargs)
        _finalizer_registry = {(None, 10): <Finalize object, callback=_close_handles, args=(2128, 2136)>, (None, 11): <Finalize object, callback=_close_handles, args=(2196, 2172)>}
        getpid     = <built-in function getpid>
        self       = <Finalize object, callback=_terminate_pool, args=(<_queue.SimpleQueue object at 0x00000173AC658E00>, <multiprocessing....aemon 944)>, <Thread(Thread-112, stopped daemon 848)>, <Thread(Thread-113, stopped daemon 1688)>, {}), exitpriority=15>
        sub_debug  = <function sub_debug at 0x00000173983E48B0>
        wr         = None
C:\Python38-x64\lib\multiprocessing\pool.py:710: in _terminate_pool
    p.terminate()
        cache      = {}
        change_notifier = <multiprocessing.queues.SimpleQueue object at 0x00000173AC674730>
        cls        = <class 'multiprocessing.pool.Pool'>
        inqueue    = <multiprocessing.queues.SimpleQueue object at 0x00000173AC632880>
        outqueue   = <multiprocessing.queues.SimpleQueue object at 0x00000173ACD24970>
        p          = <SpawnProcess name='SpawnPoolWorker-8' pid=316 parent=1028 stopped exitcode=0 daemon>
        pool       = [<SpawnProcess name='SpawnPoolWorker-7' pid=384 parent=1028 stopped exitcode=-SIGTERM daemon>, <SpawnProcess name='SpawnPoolWorker-8' pid=316 parent=1028 stopped exitcode=0 daemon>]
        result_handler = <Thread(Thread-113, stopped daemon 1688)>
        task_handler = <Thread(Thread-112, stopped daemon 848)>
        taskqueue  = <_queue.SimpleQueue object at 0x00000173AC658E00>
        worker_handler = <Thread(Thread-111, stopped daemon 944)>
C:\Python38-x64\lib\multiprocessing\process.py:133: in terminate
    self._popen.terminate()
        self       = <SpawnProcess name='SpawnPoolWorker-8' pid=316 parent=1028 stopped exitcode=0 daemon>
C:\Python38-x64\lib\multiprocessing\popen_spawn_win32.py:123: in terminate
    _winapi.TerminateProcess(int(self._handle), TERMINATE)
E   PermissionError: [WinError 5] Access is denied
        self       = <multiprocessing.popen_spawn_win32.Popen object at 0x00000173AC663970>
============================== warnings summary ===============================

@tylerjereddy
Copy link
Contributor Author

ok, we lucked out, restarting worked

tylerjereddy added a commit to tylerjereddy/scipy that referenced this pull request Jun 4, 2022
* 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..)
tylerjereddy added a commit to tylerjereddy/scipy that referenced this pull request Jun 22, 2022
* 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..)
rgommers pushed a commit that referenced this pull request Jun 22, 2022
For reference, last branching we did this: gh-15191
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance Items related to regular maintenance tasks
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants