Skip to content
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

Unable to find python3 headers #152

Closed
joaompinto opened this issue Nov 3, 2019 · 9 comments · Fixed by #168
Closed

Unable to find python3 headers #152

joaompinto opened this issue Nov 3, 2019 · 9 comments · Fixed by #168

Comments

@joaompinto
Copy link
Contributor

I am running configure --with-python-bindings on Ubuntu 19.10, the configure fails because it is unable to locate the python3 headers.

As far I could understand, the problem is related to:
PKG_CHECK_MODULES([PYTHON], [python], [], [AC_MSG_ERROR([*** python headers not found])])
On Ubuntu 19.10 the python3 PKGCONFIG file is python3.pc, CHECK_MODULE is search only for "python.pc".

@giuseppe
Copy link
Member

giuseppe commented Nov 3, 2019

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?

@joaompinto
Copy link
Contributor Author

joaompinto commented Nov 4, 2019

@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.

@rhatdan
Copy link
Member

rhatdan commented Nov 4, 2019

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

@joaompinto
Copy link
Contributor Author

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

@giuseppe
Copy link
Member

giuseppe commented Nov 5, 2019

@joaompinto yes, we can use only python3

@joaompinto
Copy link
Contributor Author

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 ?

@giuseppe
Copy link
Member

giuseppe commented Nov 7, 2019

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.

@joaompinto
Copy link
Contributor Author

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.

@giuseppe
Copy link
Member

giuseppe commented Nov 7, 2019

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

@joaompinto joaompinto reopened this Nov 7, 2019
joaompinto pushed a commit to joaompinto/crun that referenced this issue Nov 8, 2019
joaompinto pushed a commit to joaompinto/crun that referenced this issue Nov 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants