Bug #22691
closed
Fix python source package naming
Description
This email is notifying you of an upcoming deprecation that we have determined may affect you as a result of your recent upload to 'arvados-cwl-runner'.
In the future, PyPI will require all newly uploaded source distribution filenames to comply with PEP 625. Any source distributions already uploaded will remain in place as-is and do not need to be updated.
Specifically, your recent upload of 'arvados-cwl-runner-3.1.0.tar.gz' is incompatible with PEP 625 because the filename does not contain the normalized project name 'arvados_cwl_runner'.
In most cases, this can be resolved by upgrading the version of your build tooling to a later version that supports PEP 625 and produces compliant filenames. You do not need to remove the file.
If you have questions, you can email admin@pypi.org to communicate with the PyPI admin@pypi.org to communicate with the PyPI administrators.
Same for arvados-python-client, arvados-user-activity, and arvados-cluster-activity.
Updated by Peter Amstutz about 1 year ago
- Position changed from -943470 to -943469
Updated by Brett Smith about 1 year ago
setuptools introduced a change in v69.3.0 and a bugfix in v70.2.0. We could come into compliance by making sure our build tools install at least that version in their virtualenv before they do the build.
However, upgrading might require some adaptation to our build tooling too. In particular, anything that assumes the source package for $PACKAGE_NAME gets built at ${PACKAGE_NAME}*.tar.gz is going to break with this change, and will need to have similar name transformation added.
Updated by Brett Smith 11 months ago
- Has duplicate Bug #22786: Python packages distributed via PyPI not PEP 625 compliant added
Updated by Brett Smith 9 months ago
- Target version deleted (
Development 2025-06-25) - Assigned To deleted (
Brett Smith)
Updated by Brett Smith 8 months ago
Brett Smith wrote in #note-4:
setuptools introduced a change in v69.3.0 and a bugfix in v70.2.0. We could come into compliance by making sure our build tools install at least that version in their virtualenv before they do the build.
This was done a while ago in #21389, 167f35842e54f61503d07b259435f6b6ccc0fe51.
However, upgrading might require some adaptation to our build tooling too. In particular, anything that assumes the source package for
$PACKAGE_NAMEgets built at${PACKAGE_NAME}*.tar.gzis going to break with this change, and will need to have similar name transformation added.
I don't currently see anything to do. None of our CI scripts depend on this. We've gotten rid of a lot of our old sdist builds because they were part of a larger install process and now we just say pip install. It's possible there's something lurking in a Jenkins script, I'll check the obvious candidates, but it's possible we've gotten this for free as part of our general modernization efforts.
Updated by Brett Smith 8 months ago
- Target version set to Development 2025-08-06
- Assigned To set to Brett Smith
- Status changed from New to Resolved
Brett Smith wrote in #note-14:
It's possible there's something lurking in a Jenkins script, I'll check the obvious candidates, but it's possible we've gotten this for free as part of our general modernization efforts.
Doesn't look like it. The relevant Jenkins scripts just run source:build/run-build-packages-python-and-ruby.sh where the wheel glob was already flexible about name spelling and we just removed it anyway in 713d1452405279b8a5d9fdcaed451e4004f06d6e. So as far as I can tell this is done, hooray.