On Tue, Feb 11, 2014 at 02:47:57PM -0500, Thiago da Silva wrote: > Hi Justin, > > I have started the work, but it is not yet complete. We currently have > the same functions that was part of the example code. I think this is > good enough so that the existing Python libgfapi can be removed from > Gluster 3.5 dev tree. This way I can also start working to create a > separate rpm, which gluster-swift would depend on once we make the move > away from fuse.
I suggest to not do this for 3.5, but rather for 3.6. That gives you some time to prepare the package and provide it in Fedora and all. Currently glusterfs-api provides python-glusterfs (I think) where gluster-swift can depend on. Your package would have that Provides: as well. This should allow a relatively easy transition. Cheers, Niels > > I have separated the tests to their own files and we have both unit and > functional tests running automatically on Jenkins > (http://build.gluster.org). > > I'm currently working with Ben England to run some tests with his > smallfile.py project (https://github.com/bengland2/smallfile) > > I don't think it is ready yet for real world usage, but we are moving > towards that... > > Thiago > > > > > On Tue, 2014-02-11 at 19:13 +0000, Justin Clift wrote: > > Hi Thiago, > > > > How's this stuff going? Is it ready enough for real world usage? > > > > eg should we think about ripping the existing Python libgfapi code > > out of main Gluster 3.5 dev tree, and using this instead? :) > > > > Regards and best wishes, > > > > Justin Clift > > > > > > On 29/10/2013, at 1:34 PM, Luis Pabon wrote: > > > 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 > > >> > > >> Gluster-devel@nongnu.org > > >> https://lists.nongnu.org/mailman/listinfo/gluster-devel > > > > > > > -- > > Open Source and Standards @ Red Hat > > > > twitter.com/realjustinclift > > > > _______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel