Description of problem: Currently libgfapi-python is not packaged , so the consumers like vdsm, openstack.etc are not able to make use of python bindings of libgfapi. Version-Release number of selected component (if applicable): N/A How reproducible: N/A Steps to Reproduce: N/A Actual results: No package/rpm shipped for libgfapi-python product. Expected results: An rpm named libgfapi-python has to be produced out of 'libgfapi-python' project in review.gluster.org and has to be shipped with distros like 'fedora'. Additional info:
The current source of libgfapi-python has subdirs in name 'glusterfs' and setup.py list 'gfapi' as its name module name. There should be consistency in name and the consumers should get a better picture from the 'name' itself. As part of packaging, I have renamed the reference of 'glusterfs' from the source to 'libgfapi'. The patch is available in review.gluster.org ( http://review.gluster.org/#/c/9668/ ) for the review.
FWIW, I'd recommend a package name of "glusterfs-api-python" for this rpm. libgfapi bindings work really stems from and requires prior installation of "glusterfs-api".
I read the review more carefully, please don't bother considering my previous comment. I was speaking about rpm packaging, not Python module naming.
(In reply to Lans Carstensen from comment #2) > FWIW, I'd recommend a package name of "glusterfs-api-python" for this rpm. > libgfapi bindings work really stems from and requires prior installation of > "glusterfs-api". Thanks for the suggestion. Yeah, we can keep the 'rpm' name as 'glusterfs-api-python' or similar. We are discussing more on module naming part at http://review.gluster.org/#/c/9668/ .
The first draft of spec file is ready for review @http://review.gluster.org/#/c/10256/ . The spec file is compatible to make below structure for gluster namespace so that it is more portable and scalable for future use. <sitepackages>/gluster/ | -- __init__.py | | -- glupy | -- __init__.py -- glupy.py -- ........ | | -- gfapi | -- __init__.py -- gfapi.py -- ........ By above structure clients can import: >>> from gluster import glupy >>> from gluster import gfapi
It's a nitpick, but since "glusterfs" is what's being used instead of "gluster" for packaging the C API (glusterfs-api) which this package is dependent upon I'd encourage you to use "glusterfs" here also. Imports would become: from glusterfs import glupy from glusterfs import gfapi
(In reply to Lans Carstensen from comment #6) > It's a nitpick, but since "glusterfs" is what's being used instead of > "gluster" for packaging the C API (glusterfs-api) which this package is > dependent upon I'd encourage you to use "glusterfs" here also. Imports > would become: > > from glusterfs import glupy > from glusterfs import gfapi We did consider this, but we decided to use "gluster" instead. All packages related to Gluster (the community, as a whole eco-system of projects) can use the "gluster" namespace. If we use "glusterfs" there is something like a restriction on what could get included there. We would like to see different projects use the "gluster" namespace, even if they are packaged within the (main) GlusterFS project. Additional tools and utilities can provide shared Python packages/libraries, things like this are possible now (fictional example): # import functions to get statistics from tcpdumps from gluster import wireshark
Hi Humble, did you make any progress here? I'd like to see the Python libgfapi bindings in Fedora, but can not find the package review for it. Can you link that here? Thanks!
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days