Automatically build and upload PyPI packages on release #207
Conversation
|
If you're OK with this, I'll make a PR against |
|
@dralley Wouldn't this be a problem since we can't statically link librpm in, among other things? |
|
@Conan-Kudo Well, right now it only builds source distributions. That means you have to have all of the build dependencies installed, but when you install the Python package the build process is entirely automated away. It's somewhat limiting but still better than nothing. The other form of Python package is a pre-compiled binary "wheel" distribution. I've been working on this for a good part of the afternoon but haven't gotten it working yet. These packages are effectively statically linked although my understanding is that the actual process is a little bit more complex than that. For the latter kind of package, once I actually get it to work, it would be entirely standalone. |
|
To amend my previous comment a bit: you can actually build a binary wheel of createrepo_c just fine... but you can't upload it to PyPI unless you've built it a certain way, that accomplishes the "effectively statically linked" part of what I just mentioned. To do that, you have to build it on a special platform ( ^ That sounds crazy, but it's the official way of doing things. It's how every compiled package on PyPI ( |
dralley
force-pushed
the
master
branch
3 times, most recently
from
f3dae25 to
672a389
Compare
dralley
changed the title
|
So the wheel-building component of this PR is blocked on a Python ecosystem issue that I (apparently) uncovered: pypa/auditwheel#230 But packaging source distributions on release can still move forwards, if the general principle of this PR is something you are open to. |
dralley
force-pushed
the
master
branch
3 times, most recently
from
c872b60 to
342074c
Compare
dralley
changed the title
|
So this works now, the only thing missing is the "secrets" for uploading to PyPI. |
| @@ -28,6 +28,7 @@ if (NOT SKBUILD) | |||
| endif (NOT SKBUILD) | |||
|
|
|||
| EXECUTE_PROCESS(COMMAND ${PYTHON_EXECUTABLE} -c "from sys import stdout; from distutils import sysconfig; stdout.write(sysconfig.get_python_lib(True))" OUTPUT_VARIABLE PYTHON_INSTALL_DIR) | |||
There was a problem hiding this comment.
It's been a while so I don't remember why it was that this was necessary.
dralley
force-pushed
the
master
branch
3 times, most recently
from
4bf9a2c to
915604d
Compare
dralley
force-pushed
the
master
branch
2 times, most recently
from
d33ed17 to
96aa33e
Compare
|
This issue is still blocking publishing binary packages: pypa/manylinux#823 However, automating publishing the standard "source distributions" as we are currently doing would work fine, if you're interested in merging this. |
Using Github Actions closes rpm-software-management#145
dralley
force-pushed
the
master
branch
7 times, most recently
from
d605c7b to
fd5e8b6
Compare
dralley
force-pushed
the
master
branch
9 times, most recently
from
5d5ce48 to
044d9e0
Compare
|
Recreating this PR from a different local branch. |
Don't feel obligated to merge this -- we can continue maintaining the package ourselves just fine.
But it would simplify things if the packages were just automatically created and uploaded on every release, especially if we ever start creating binary wheels that would work across different Linux distros (see the discussion here: [0]).
The RPM team or someone from the RPM team would need to be a co-maintainer on the
createrepo_cPython package, and add their credentials to thesecretsstorage on this repository [1][0] #145 (comment)
[1] https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets#creating-encrypted-secrets