Reused actions maintained by PyPA

[proppy]

The Python Packaging Authority is now maintaining two actions for building and publish wheels:

• https://github.com/pypa/cibuildwheel
• https://github.com/pypa/gh-action-pypi-publish

Did you consider reusing those?

[umarcor]

As discussed in The-OpenROAD-Project/OpenROAD#1424, wrapping twine in a shell script which is executed in a Container Action is unnecessarily complex. In this context, https://github.com/pyTooling/Actions/blob/main/.github/workflows/PublishOnPyPI.yml#L70-L80 is equivalent to https://github.com/pypa/gh-action-pypi-publish/blob/master/twine-upload.sh#L51-L54, without building and spawning a container. Nevertheless, we can add the "VERIFY_METADATA" and "TWINE_EXTRA_ARGS" options if necessary. Do you have a use case for them?

With regard to cibuildwheel, honestly, I don't know what to do. We currently support three different build commands/procedures (https://github.com/pyTooling/Actions/blob/main/.github/workflows/Package.yml):

• python -m build
• python -m build --no-isolation
• python setup.py

The first two are expected to be used in repositories containing a pyproject.toml, while the third one is for "backwards compatibility" (a requirements.txt file or a list of dependencies). Given the inconsistency in Python packaging (setup.py, setup.cfg, pyproject.toml, etc.) it was not easy to find a solution that suits the needs of the current users of pyTooling/Actions.

Is cibuildwheel a replacement for Package.yml which can handle those cases? Or, is the proposal to have cibuildwheel as a fourth alternative in workflow Package? If used as a replacement, the ExamplePipeline is designed so that any of the jobs can be replaced by an alternative implementation. For instance, in https://github.com/VHDL/pyVHDLModel/blob/main/.github/workflows/Pipeline.yml#L82 a custom "VerifyDocs" job is used.

[umarcor]

Upon further thinking, all the consumers of pyTooling/Actions are Python-only packages. As far as I understand, in those cases a single wheel can be used regardless of platform (OS or version). That's why we had not considered multiple builds. @proppy do you have a use case that requires building multiple wheels?

[proppy]

yes The-OpenROAD-Project/OpenROAD#1424 would require to build wheels for a variety of architectures.