Unable to find python3 headers about crun HOT 9 CLOSED

thanks for the report. I'll take a look at it.

While currently available, the python bindings are not really used/supported at the moment, just out of curiosity, are you planning on using them?

from crun.

@giuseppe I don't have a "business" use case for it, but I would like to experiment more with container management, and I am more productive in Python, while most of the current container related tools/libraries are in Go. Because of this I have started a Python "pure" approach (https://github.com/joaompinto/pylibcontainer) but it stills needs a lot of work, and it is mostly a wrapper around kernel syscalls. It would make more sense to leverage the libcrun interface.

If there are no plans to have it widely maintained I will take ownership of the issue when I have some more spare time, I will need to revive my automake/autoconf/C development skils :)

I am not a big fan of some of "Docker" methods for building and distributing containers, podman/buildah are nice, but in the "Golang" domain, so in the long term, If I am able to produce minimal stable Pythons bindings I expect to provide some container management options to Python developers.

from crun.

Sounds cool. Any help from you @joaompinto Would be appreciated.

from crun.

Since Python2 will be EOL soon, would be acceptable to provide Python3 only bindings ?

from crun.

@joaompinto yes, we can use only python3

from crun.

I am thinking about the benefits vs effort of the work on this issue, taking in account that:

a) Distributing python packages with native library dependencies is tricky
b) Rewriting the crun (cli) specific features in Python provides little benefit
c) Many other "consumers" (e.g. podman ) are already using the binary runtime configuration

Are there some library features that might be interesting from a container management point of view that arenot available trough the "crun" CLI ?

from crun.

I've played slightly with them: https://github.com/giuseppe/oci-auto-capabilities/blob/master/oci-auto-capabilities.py but honestly I think there are not many benefits. The same script can be written using the Podman CLI (even if with less control on the kind of the capabilities).

The OCI runtime works at a low level and many importants parts like storage or networking are out of scope. This limits significantly what we can provide via the Python hooks.

from crun.

Based on this assessment I am closing this issue, I will create a new one for the removal the current python bindings configure option and related documentation.

I will do some more research for a better option for a Python framework, eventually similar to "libpod" but without the podman dependency. A thin runtime layer: python3 (stdlib) + python-libpod + runc binary.

from crun.

I don't think we need to remove the current ones. They can be useful if all you need is an OCI runtime.

from crun.