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

Python 3.13 wheels #80

Open
henryiii opened this issue Oct 7, 2024 · 6 comments
Open

Python 3.13 wheels #80

henryiii opened this issue Oct 7, 2024 · 6 comments

Comments

@henryiii
Copy link
Member

henryiii commented Oct 7, 2024

There are no 3.13 wheels. 3.13.0 has been released.

@HDembinski
Copy link
Member

HDembinski commented Oct 10, 2024

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
Copy link
Member Author

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

@HDembinski
Copy link
Member

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
Copy link
Member

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

@henryiii
Copy link
Member Author

henryiii commented Oct 10, 2024

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
Copy link
Member Author

henryiii commented Oct 11, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants