-
Notifications
You must be signed in to change notification settings - Fork 188
RFE: Add support for building python pip packages #467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Rename setup.py to setup.py.in so that the version variables can be autopopulated by automake/m4. This will be used in subsequent commits for building python wheels. Wheels are often built in containers, and the build containers don't have knowledge of automake, its configurations, and its environment variables, so we need to pre-populate the version information. Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
Change the include of seccomp-syscalls.h from: #include <seccomp-syscalls.h> to: #include "seccomp-syscalls.h Change the include directive of seccomp-syscalls.h to be a local (rather than system-wide) include. This change is required for building python wheels inside of containers where the system-wide include path will likely not include the local path to seccomp-syscalls.h Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
Add two new make targets: python-wheel: build a python wheel for this system python-wheels: build the series of python wheels for pip When building the wheels for pip, cibuildwheel utilizes Docker containers. Because of this, it cannot reach outside of the build directory, src/python, so any files outside of this folder - libseccomp.a, seccomp.h, etc. - must be copied into the src/python folder. Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
Add three python continuous integration jobs: build-wheel: Build a wheel for the native build system build-wheels: Build wheels suitable for uploading to pip flake: Python lint checker Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
| @echo " dist-gzip: build a release tarball" | ||
| @echo " coverity-tarball: build a tarball for use with Coverity (opt)" | ||
| @echo " python-wheel: build a python wheel for this system" | ||
| @echo " python-wheels: build python wheels for distribution to pip" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's just me, but I'm fairly certain I'm going to be forever typing the wrong target as they only differ in that plural 's' at the end; would changing python-wheels to python-wheels-pip be reasonable?
| # Enhanced Seccomp Library Python Module Build Script | ||
| # | ||
| # Copyright (c) 2012 Red Hat <pmoore@redhat.com> | ||
| # Copyright (c) 2012-2025 Red Hat <pmoore@redhat.com> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo? Did you mean to add a line for you/Oracle?
This patchset adds support for building Python wheels that are suitable for upload to pip.
I uploaded the wheels generated by the Ubuntu 24.04 continuous integration run to the Test PyPi pip repository. Note that I have not uploaded any wheels to the formal pip repository. (We'll likely need to create a seccomp organization in pip just like the seccomp organization in github.)
For local testing, I used the following commands on my machine:
The above commands will load the package into
~/.local/lib/{PYTHON_VERSION}/site-packages/. With the packages loaded into the local python repo, any python program on that machine (run by the same user) can utilize the newly-built packages. For example, I ran several built-in tests in thetests/folder without updating thePYTHONPATHenvironment variable.