[Gluster-devel] Glupy bugs: found the solution?
lpabon at redhat.com
Tue Oct 29 13:34:33 UTC 2013
On the python bindings side, we have hired a new developer to spend
his time divided between gluster-swift and the python bindings for gfapi
(and probably Java binding on some future date). His name is Thiago da
Silva and he started a few weeks ago.
The gluster-swift project will require, in the near future, to move
from using FUSE to libgfapi, and so we really need to the python
bindings to become a real project: python exceptions, unit tests,
functional tests, documentation, releases, etc.
We are also planning on moving the bindings away from the glusterfs
repo to a new repo. We have been really busy working on SWAuth for
Gluster-swift, but we plan on using the same development workflow as
gluster-swift in python-libgfapi repo.
Here is the repo information:
Public Repo: https://github.com/gluster/libgfapi-python (for some reason
it is not syncing with Gerrit. I'll ping Avati)
On 10/28/2013 03:28 PM, Justin Clift wrote:
> On 27/10/2013, at 8:37 AM, Niels de Vos wrote:
>>> Yeah, that's why I was thinking it was libgfapi stuff getting pulled in
>>> not Swift. The import line in your pdf needs updating btw, as the
>>> import line for current git head needs to be:
>>> from gluster import gfapi
>> Ah, right. I'm not sure I'll update that because at the time of the
>> presentation one needed to use the git repository. During the Gluster
>> Community Day in Stockholm someone (sorry, can't remember the name)
>> asked if gfapi.py could not be included in the packages. Good question,
>> and it showed I wasn't the only one who would benefit from that ;-)
> Kind of thinking this through further, gfapi.py is kind of serving two
> roles at the moment (import + demo).
> Should we improve that by moving the import code into a "more proper"
> gfapi.py under api/src/, keeping the Python demo code in the examples
> ("gfapi-demo.py" or similar?)
>>>> the Python package 'gluster' will be the base for other modules. Hence
>>>> we have created put the api bindings in gluster/gfapi.py. I think it
>>>> would make sense to rename the Glupy module gluster.glupy. If it can be
>>>> placed in /usr/lib/python2.6/site-packages/gluster/glupy.py things would
>>>> be even nicer :)
>>> That would make the import line:
>>> from gluster import glupy
>>> Wouldn't it? No objections to that, it's fairly simple and pretty logical. :)
>> Yes, that's my suggestion. I am not maintaining or developing Glupy, so
>> it is not my call and I have no insight if this would make things more
>> complex somewhere else. I'm still planning to have a look at Glupy, but
>> I have not found the time to do so yet...
> Sure, np. Jeff was wanting to hand the code off to someone else, either
> myself or Ram as we both put time into it. Not sure if Ram "officially"
> picked it up or not. ;)
> I'd be happy to, but there is some technical challenge there... I don't
> understand Python Ctypes at all, and it's not absorbing into me head
> (have tried). :(
> + Justin
> Open Source and Standards @ Red Hat
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel