RFE: make the python bindings available via pip

[vasanthaganeshk]

[pcmoore]

I will consider it, but I consider this to be extremely low priority at the moment (that can always change).

[pcmoore]

For future reference, Python documentation on packaging/distributing code:

• https://packaging.python.org/distributing

[maxking]

Thanks @pcmoore for the comments on the PRs. I was hoping to help out on packaging the python bindings and started looking into it last night.

Some of the quick fixes were adding the MANIFEST.in and update the setup.py files. I was able to get the updated setup.py to work with pip install, but it sure needs more work to actually work with the development version (I haven't looked into the failure of #217 yet, but maybe soon).

IMO, it would make sense to carve out the Python bindings to a separate repo for a better dev/test/release workflow. I have worked on Python projects, but not too much on Cythonized ones, but I am happy to help out in whatever capacity I can.

I was hoping to help out on setting up the docs after fixing #61 (which probably would be simplified if we move this to a new repo, although, idk how sphinx the Python documentation tool handles cython files).

[drakenclimber]

From @pcmoore's comment in Issue #216:

We basically need to decide if we want to continue to support the Python bindings as part of the main libseccomp source distribution or if we want to split them out like we do for the golang bindings.

I like the idea of splitting the python bindings out of the main libseccomp package, and I also agree that it's fairly low priority for me. If someone else is interested in picking up the work, I would gladly help review it, though :).

[rhatdan]

BTW I agree that the python bindings should be in a separate repo. Although I am not volunteering. :^)

[maxking]

If someone with permissions to create a new repo under the seccomp org can set it up, I can pull the Python bindings out of the repo and create a PR.

There are couple of changes that I foresee:

• Use Python native build tooling, setup.py build should be enough
• Version numbers can be hardcoded in setup.py or be picked up from git tags instead (using setuptools-scm package) if need be.
• Dynamic binding to main libseccomp instead of static binding. (Already proposed in RFE: dynamically link the Python bindings against the main libseccomp library #217)

I haven't looked too much into test harness to see if there is a good way to port them out to use native python tests via pytest or nose2 style testing frameworks.

Finally, some additional documentation to build distribution packages both source and binary distributions.

[pcmoore]

I'm going to tentatively mark this for v2.6, which really just means "sometime after we get v2.5 out the door". Getting v2.5 finished is our priority right now, we can revisit this issue later.