search

sighingnow / libclang

(Unofficial) Release libclang (clang.cindex) on pypi.
https://pypi.org/project/libclang
Other
81 stars 21 forks source link

Publish to PyPI in workflow? #29

Closed nullableVoidPtr closed 1 year ago

nullableVoidPtr commented 2 years ago

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.

sighingnow commented 2 years ago

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.

JhnW commented 2 years ago

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

sighingnow commented 2 years ago

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.

nullableVoidPtr commented 2 years ago

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

2bndy5 commented 2 years ago

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.

sighingnow commented 1 year ago

Addressed by https://github.com/sighingnow/libclang/commit/66c8a47972911e1a1db36e7bc5e7e471d0b391fb. The generated artifacts will be uploaded to pypi from github actions directly.

2bndy5 commented 1 year ago

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).

sighingnow commented 1 year ago

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".