search

scikit-hep / pyhepmc

Easy-to-use Python bindings for HepMC3
https://scikit-hep.org/pyhepmc/
BSD 3-Clause "New" or "Revised" License
21 stars 11 forks source link

Python 3.13 wheels #80

Open henryiii opened 1 month ago

henryiii commented 1 month ago

There are no 3.13 wheels. 3.13.0 has been released.

HDembinski commented 1 month ago

I fixed a couple of changes in dependencies and now the package is back in working condition. CI has been changed to build 3.13. I also changed the CI scripts to adapt them to the iminuit ones, so let's see whether that all works. If you have time to help with that, I would appreciate PRs.

henryiii commented 1 month ago

I can take a look. Would you like to use scikit-build-core? I can probably convert to that.

HDembinski commented 1 month ago

Yes, but you need to keep the logic which generates the license. I quickly tried to convert and that kept me with the current system.

HDembinski commented 1 month ago

Anyway nothing to be done for 3.13 anymore, building the wheels works, I will finish it up.

henryiii commented 1 month ago

Where are you putting the license? Currently there are three spots: trove classifiers (which are the canonical location for license information), a free form field that is really designed just for small snippets of arbitrary text (the long contents get truncated on PyPI, and newlines are technically invalid in the email.message format the metadata is stored in, they are supposed to be converted to a single space), and license files, what are the full text of the license is stored in the wheel metadata directory.

If it’s the free text field, that technically can be done, but probably should wait until the dynamic meditate plug-in system is finalized. But that's really not what this field is for.

If it’s the files, you can write to that metadata directory with CMake. Though you can also just have as many of them as you like.

PEP 639 will redo the license info by requiring an SPDX identifier expression, deprecating the free-form field, and providing a better way to specify which license files go in the metadata directory (but scikit-build-core already lets you do that). So I'd recommend the license text just be an SPDX expression while waiting for things like PyPI to support PEP 639.

henryiii commented 1 month ago

SciPy is now doing this by cat $PROJECT_DIR/tools/wheels/LICENSE_linux.txt >> $PROJECT_DIR/LICENSE.txt inside the cibuldwheel before all script! That's awful and a direct violation of PEP 621, which states the metadata is statically determinable by any tool if it's specified in the project section. They also are not including both license files in the .dist-info directory, which they are supposed to do (but in that case, the one file they are providing is the merged file, so that's not wrong, it's just not the way this designed). I think this is due to a limitation of meson-python, which doesn't have a way to specify multiple license files. Scikit-build-core can do this, though. They do claim they will fix this once PEP 639 is implemented.

See https://github.com/scipy/scipy/blob/1adc8cb7a37e09444632a86afea5ee1d07f3e3c5/pyproject.toml#L37-L39 and the tools/wheels/cibw_before_build_linux.sh scripts. LICENSE_bundled.txt is never used anywhere, AFAICT, and is not in the wheel. (https://inspector.pypi.io/project/scipy/1.14.1/packages/64/68/3bc0cfaf64ff507d82b1e5d5b64521df4c8bf7e22bc0b897827cbee9872c/scipy-1.14.1-cp310-cp310-macosx_10_13_x86_64.whl/ ) Scikit-build-core would have put it there by default and has options to customize what files go in.