(updated) Trusted publishing directly from the LLVM CI
Hi @trolldbois - I noticed there have been a few new versions of clang since the last release on PyPI for the clang bindings. It would be great to get wheels for clang 18 and 19 uploaded. I expect clang 20 will also be coming out this upcoming March.
Correct me if I'm off, but it seems like you might not be as active these days on GitHub as in the past. If you're open to adding another maintainer (which would ostensibly be good so all of the burden doesn't fall on a single person, or point of failure), then I'd like to help out if you can add me to the project on GitHub and PyPI (username: rmast). The gist of what I'm thinking for making updated releases a bit more timely can be seen in PR #20.
Perhaps we can see if the workflows for publishing updated wheels would be accepted by the upstream LLVM project to further help increase the odds of new versions being released in a timely manner.
The PR that adds a pyproject.toml file for building a wheel from a copy of the LLVM source code/repository is https://github.com/llvm/llvm-project/pull/125806 -- if you want to take a look and leave any review comments that might be good, at the moment the challenge seems to be getting reviewers who have some familiarity with Python packaging.
I left a comment over there, to confirm I'm happy to integrate with the upstream LLVM github CI whenever they are ready
The owners/maintainers of the LLVM org on PyPI are willing to take ownership. There's some discussion and their PyPI user names in this thread: https://discourse.llvm.org/t/moving-projects-into-the-llvm-org-on-pypi/88868/2
@trolldbois the PRs for moving over to the LLVM github CI are in review, can you transfer ownership to @boomanaiden154 or @stellar so they can move it into the LLVM PyPI org?
What exactly is the difference between this package and the libclang package? It seems like they both publish python bindings.
The clang package is just the Python binding files, the libclang package adds platform specific wheels with precompiled libraries. In general it seems people like the convenience of libclang as a dependency because it generally just works -- what I'm thinking for merging them into the LLVM monorepo is:
- the
clangpackage continues to just publish the pure Python bindings - the
libclangpackage gets changed to use theclangpackage as a dependency to supply the pure Python bindings rather than providing a copy of its own, and instead becomes a way people can "opt-in" if they want the precompiled native libraries
So they're both the libclang python bindings, it's just that one (the clang package) does not ship the actual native artifacts to actually be useable? How are you typically expected to use it? A system provided libclang shared object?
LLVM invited to pypi project
So they're both the libclang python bindings, it's just that one (the
clangpackage) does not ship the actual native artifacts to actually be useable? How are you typically expected to use it? A system providedlibclangshared object?
Yes, libclang should be installed with the system's package management system. This avoid the problem of have to trust binary libraries stored & distributed through pypi.