search

zopefoundation / zope.i18nmessageid

Other
1 stars 11 forks source link

5.1.0 release is missing sdist (and non-Windows wheels) #33

Closed mgorny closed 2 years ago

mgorny commented 2 years ago

The newest 5.1.0 release of zope.i18nmessageid lacks the sdist tarball and features only Windows wheels. This makes it impossible to install it via pip on any other platform, i.e.:

$ pip install zope.i18nmessageid==5.1.0
ERROR: Could not find a version that satisfies the requirement zope.i18nmessageid==5.1.0 (from versions: 3.4dev-r73161, 3.4.0, 3.4.2, 3.4.3, 3.5.0, 3.5.1, 3.5.2, 3.5.3, 3.6.0, 3.6.1, 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.1.0, 4.2, 4.3, 4.3.1, 5.0.0, 5.0.1)
ERROR: No matching distribution found for zope.i18nmessageid==5.1.0
icemac commented 2 years ago

I added the necessary secrets so GHA can publish the releases and restarted the release job. See https://github.com/zopefoundation/zope.i18nmessageid/actions/runs/3404312740

The missing wheels and the sdist should appear in the next minutes.

CC: @dataflake

mgedmin commented 2 years ago

Which CI job is responsible for building and uploading the sdist? I can't find one. All of the jobs (except for the super slow ARM manylinux one) are finished and I still don't see an sdist on PyPI.

Usually the sdist gets uploaded by zest.releaser. This breaks when the person doing the release doesn't have PyPI publishing permissions for the package in question. It may be nice if we had CI doing uploads, but that may require some updates to the meta/config template.

I think I'll build and upload the sdist manually this time to unbreak people's workflows.

icemac commented 2 years ago

@mgedmin I think so, too, that the sdist is uploaded by the release process. At least zest.releaser does it. (We have https://github.com/zopefoundation/zope.i18nmessageid/blob/8c010943e271b47311b0328d9be5fead53389898/setup.cfg#L6-L7 to prevent it from creating wheels.)

dataflake commented 2 years ago

I don't use zest.releaser and had to manually upload all source distributions so far. I was wondering why that wasn't part of the GHA steps.

I don't want to open a Pandora's box here, I'm currently looking at the build issues several packages have on macOS/Python 3.11, there's enough to do. I'm also looking at the cibuildwheel experiment on a branch in the ExtensionClass repo. I don't believe the macOS issues are caused by which wheels are provided and how they are built, or if a package declares a dependency in both setup_requires and install_requires. It feels like a setuptools bug where setuptools doesn't find/select a locally built egg from a previous step and tries to build it again.

mgedmin commented 2 years ago

I don't use zest.releaser and had to manually upload all source distributions so far.

There's no requirement to use zest.releaser, it's just convenient.

I was wondering why that wasn't part of the GHA steps.

Most likely because nobody added it to the GHA steps. We've been using the same release process (update version and changelog, commit, tag, build sdist, upload, bump version and changelog, push) since Subversion times when no convenient centralized CI even existed.

I'd be in favor of updating GHA to upload sdists (and pure-python wheels for packages that have no C modules) for git tags, with twine --skip-existing-sdists, to allow people who currently use zest.releaser to continue using zest.releaser.

I have not plans of creating a PR myself.

mgorny commented 2 years ago

Thank you for solving this!