Release v0.5.0
roryyorke opened this issue · 11 comments
- Finalize release notes
- Check source tarball builds
- Tag
- upload to PyPI
Add setup.py check for Numpy v1.23?not needed, v1.23.1 fixes the problem-
Notify conda-forge feedstock?conda-forge/slycot-feedstock update PR
See https://github.com/python-control/Slycot/wiki/v0.5.0-release-notes-draft for draft release notes
On Numpy v1.23:
-
As I understand, we should in principle be able to build against (i.e., with) Numpy v1.22, and still install with v1.23. I'm not 100% sure how to test that -- I guess I could build a wheel and test?
-
Is it worth adding detection of Numpy v1.23 to warn anyone trying to build Slycot with that version?
-
How do we handle this build problem in conda-forge? Does that build against a very old version of Numpy anyway ?
Oh, Numpy v1.23.1 sorts out the build issue: https://github.com/numpy/numpy/releases/tag/v1.23.1, so that's at least not a worry. I'm not having luck with python -m build yet, though.
I think my build problems are due to scikit-build/scikit-build#524.
On Numpy v1.23:
- As I understand, we should in principle be able to build against (i.e., with) Numpy v1.22, and still install with v1.23. I'm not 100% sure how to test that -- I guess I could build a wheel and test?
This was the case in the current CI until 1.23.1 came out;
https://github.com/python-control/Slycot/runs/7133906655?check_suite_focus=true#step:6:110
https://github.com/python-control/Slycot/runs/7134112685?check_suite_focus=true#step:8:34
- Is it worth adding detection of Numpy v1.23 to warn anyone trying to build Slycot with that version?
The pyproject.toml prevents a (PEP517 based) build with 1.23.0, that should be enough.
- How do we handle this build problem in conda-forge? Does that build against a very old version of Numpy anyway ?
It's the same mechanism: build and host: numpy!=1.23.0, run: {{ pin_compatible('numpy') }}.
I think my build problems are due to scikit-build/scikit-build#524.
I just tried python -m build . with current master, and it sucessfully built a wheel in an isolated build venv with numpy 1.23.1. What's your error message?
I'm on Ubuntu 20.04. The build finds the system Python 2 (!) Numpy headers. After apt-uninstalling that and Python3 system numpy packages, I can python -m build . fine; I've installed the resulting wheel into a venv, and slycot.test() succeeds.
So the sdist tarball is fine, and obviously the various CI builds pass, so this is possibly a problem specific to my system.
FWIW, I thought scikit-build/scikit-build#712 might fix this (with a modified CMakeLists.txt in Slycot), but Scikit-build invoked CMake like this (replacing spaces with newlines); notice the mix of virtual environment (/home/rory/tmp/slycot-v0.5.0/ and system (/usr/include/Python3.8, etc), which, reasonably enough, seems to remove CMake's FindPython's chances of finding the venv libs.
cmake
/home/rory/src/slycot
-G
'Unix
Makefiles'
-DCMAKE_INSTALL_PREFIX:PATH=/home/rory/src/slycot/_skbuild/linux-x86_64-3.8/cmake-install
-DPYTHON_VERSION_STRING:STRING=3.8.10
-DSKBUILD:INTERNAL=TRUE
-DCMAKE_MODULE_PATH:PATH=/home/rory/tmp/slycot-v0.5.0/build1/lib/python3.8/site-packages/skbuild/resources/cmake
-DPython3_EXECUTABLE:FILEPATH=/home/rory/tmp/slycot-v0.5.0/build1/bin/python
-DPython3_INCLUDE_DIR:PATH=/usr/include/python3.8
-DPython3_LIBRARY:PATH=/usr/lib/x86_64-linux-gnu/libpython3.8.so
-DPython3_NumPy_INCLUDE_DIRS:PATH=/home/rory/tmp/slycot-v0.5.0/build1/lib/python3.8/site-packages/numpy/core/include
-DPython_EXECUTABLE:FILEPATH=/home/rory/tmp/slycot-v0.5.0/build1/bin/python
-DPython_INCLUDE_DIR:PATH=/usr/include/python3.8
-DPython_LIBRARY:PATH=/usr/lib/x86_64-linux-gnu/libpython3.8.so
-DPython_NumPy_INCLUDE_DIRS:PATH=/home/rory/tmp/slycot-v0.5.0/build1/lib/python3.8/site-packages/numpy/core/include
-DPYTHON_EXECUTABLE:FILEPATH=/home/rory/tmp/slycot-v0.5.0/build1/bin/python
-DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.8
-DPYTHON_LIBRARY:PATH=/usr/lib/x86_64-linux-gnu/libpython3.8.so
-DPYTHON_NumPy_INCLUDE_DIRS:PATH=/home/rory/tmp/slycot-v0.5.0/build1/lib/python3.8/site-packages/numpy/core/include
-DSLYCOT_VERSION:STRING=0.4.0.99
-DGIT_REVISION:STRING=fa06521af4645ce4291fd29fbf80066efc20b2ef
-DISRELEASE:STRING=False
-DFULL_VERSION=0.4.0.99.gitfa06521
-DCMAKE_BUILD_TYPE:STRING=Release
That's indeed strange. The build module normally sets up an isolated build environment which does not give access to the system sitelib.
Did by any chance python -m build . invoke python from Python 2? If you are not in a venv, that's a common (user) error. In a bare system environment, always use python3 or python3.X. Now the cmake modules still look for a python3 interpreter and modules and don't care about the python2 enviroment which build might have set up.
I was running python3 -m build . from the base (system) environment. I haven't installed build for Python2.
I'm reasonably sure scikit-build/scikit-build#524 is still relevant; I could reproduce the build problem with setup.py bdist_wheel in a venv. Also, from the description of find_path, one can see that the "PATHS" argument to find_path is consulted nearly last. A simple fix for scikit-build would be to use the HINTS argument, which is intended for introspectively-discovered paths. (This doesn't fix FindPython use, which looks like it should be much nicer.)
Thanks for the updates to the release notes. I forgot to add a list of contributors, which I'll do now---then I think that's done?
All done!