Re: [Gluster-devel] Glupy bugs: found the solution?

[Luis Pabon]

Hi guys,
    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)
Gerrit:  http://review.gluster.org/libgfapi-python

- Luis

On 10/28/2013 03:28 PM, Justin Clift wrote:

On 27/10/2013, at 8:37 AM, Niels de Vos wrote:
<snip>

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?)

<snip>

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

twitter.com/realjustinclift


_______________________________________________
Gluster-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/gluster-devel