[WIP] Automate release process #5045
Conversation
|
❤️ !!! |
|
I think Napari is a pure python package correct? If so, this will need to be adapted to compile manylinux and windows. Which begs the question, is it more appropriate to do this in the wheel builder? |
|
@hmaarrfk no idea at all, this is really out of my scope. Just want to start the discussion 🙂 |
|
Yes, napari is pure Python. @hmaarrfk does GitHub actions not allow compiling on Linux and Windows? I know we (napari) also create our app bundles on GitHub actions and iirc that is machine dependent. My goal is to bring wheel building to this repo. The multiple repo dance at release time is frustrating to say the least. |
|
I should probably add this to the README or some knowledge base location. Let me know if you have an appropriate file for it. The reason behind the original wheel builder is that publishing binary wheels to pypi requires the wheels to abide by certain standards. Whether that be older versions of OSX, or older versions of libc (for linux) so that they may be installable on a wide variety of computers.Therefore, it requires some care as to exactly what compilers, and what versions of linux are used at that time. This added complexity to a main repo isn't always desirable. In fact, being able to iterate on the release process seperately is one reason why conda-forge has been able to release nearly the full scientific for python 3.9 so quickly. So the wheel building process is interested in building with backward compatibility as the #1 priority, with 1 build for each python + platform combination, but the development repo is more interested in testing software on the types of machines most users will actually use: Qt/NoQt, Python Optimize, and we can make assumptions that we probably don't need 3 builds for arm, but rather test ARM on Python 3.8 and assume that the wheel builder should be bale to take care of 3.6, and 3.7 rather easily. |
|
So the wheel building process is interested in building with backward compatibility sure, but wheel builds happen on tags, or on a schedule, rather than on each PR. I don't see the independence of the wheel builds as a blocker — they would simply live in different config files. |
|
Hey @scikit-image/core, |
Description
Starting a discussion: some machinery to automate our releasing process.
Kindly stolen from our friends at napari.
Checklist
./doc/examples(new features only)./benchmarks, if your changes aren't covered by anexisting benchmark
For reviewers
later.
__init__.py.doc/release/release_dev.rst.