Publish to PyPI in workflow?

Question

Publish to PyPI in workflow?

nullableVoidPtr opened this issue 2 years ago · 8 comments

Hi,
I've noticed that the actions configured only compiles and uploads artifacts; have you considered using the official PyPI publisher action pypa/gh-action-pypi-publish to automate uploading to PyPI? You can test the workflow against TestPyPI first, and it does require an API key secret to be configured first.

Answer 1 · 2022-05-02T12:30:43.000Z

Thanks for the suggestion.

I currently have no plan for that, as repeating upload to PyPI will fail, and upload artifacts after building then upload them manually leaves more flexibility for me.

Answer 2 · 2022-05-03T09:29:25.000Z

Automatic package publication is a much safer solution in terms of attacks on software sources.

Answer 3 · 2022-05-05T02:15:15.000Z

Automatic package publication is a much safer solution in terms of attacks on software sources.

Good point! As looks that many packages start to depend on this artifact.

Will be fixed before next release.

Answer 4 · 2022-05-05T06:02:20.000Z

It may be useful to use pypa/cibuildwheel, it does PyPI publishing and also auditwheel, which is important for binary extensions.

Answer 5 · 2022-06-26T02:38:27.000Z

Uploaded several wheels to pypi (simultaneously) might require consolidating all the current workflows into 1 workflow that uses a matrix for the variously supported platforms. I'm willing to help if needed.

Answer 6 · 2022-08-01T13:16:36.000Z

Addressed by 66c8a47. The generated artifacts will be uploaded to pypi from github actions directly.

Answer 7 · 2022-08-01T14:51:46.000Z

Well, it doesn't use cibuildwheel, but if it works, then it works.

And, it doesn't use auditwheel (or delocate).

And, I believe the manylinux2014 tag is deprecated. Plus, those wheels are supposed to be "built on CentOS 7 which will reach End of Life (EOL) on June 30th, 2024." ^*cite

None of this would've been a concern with cibuildwheel (+ qemu for aarch64).

Answer 8 · 2022-08-02T03:35:57.000Z

We ensure the shared library libclang.{so,dylib} requires no extra dependency except libc (and libc++ on MacOS) so there's no need for auditwheel and delocate.

That's also our orignal target of this project.

And, I believe the manylinux2014 tag is deprecated.

Deprecation of the building environment (and target) is OK for us as our goal is providing the best backwards compatibility so that this library can run as more computers as possbile.

As long as there's user who need that, then it isn't "deprecated".