---------- Forwarded message ---------- From: Niklas Lindström <[EMAIL PROTECTED]> Date: Jun 15, 2007 3:19 AM Subject: Re: [rdflib-dev] rdflib_tools To: Matt <[EMAIL PROTECTED]>
Hi Matt! Ah, yes, I forgot that. A namespace package sounds about right for the stuff "rdflib.tools" would be. Though I think any pros/cons should be discussed - for instance, I'm not sure about the usefulness of (formally) allowing anyone to put code within the package namespace - the risk of confusion and/or name-clashes seem high (in fact, I think adding "RDFLib" in the "no endorsement" clause of the license would formally prohibit this; but I'm not sure). The plus-side is to keep the distributive aspect apart from the logical package modularization - Zope3 and Paste/PasteScript/PasteDeploy are good examples to look at. BTW, you only replied to me; if you intended to send this to the rdflib-list, feel free to forward this reply as well (it was written with that in mind). Best regards, Niklas On 6/14/07, Matt <[EMAIL PROTECTED]> wrote: > how about just designate a namespace for rdflib and ask people to use > that in the top level of packages they create and of course submit to > PyPI. I have something I was about to put up on PyPI called > bioeng5.rdflibextensions where bioeng5 is a namespace that has meaning > to me but not many others. it might be better for me to use > rdflib.bioeng5.rdflibextensions or something like that, so whe > setuptools installs it it at least gets put into the common root of > rdflib. > > Matt > > > On 6/14/07, Niklas Lindström <[EMAIL PROTECTED]> wrote: > > Hello! > > > > I think a separate package would be good. To keep RDFLib as a core > > package seems fine; this tool package could then become more rich than > > would suite a core package, e.g. a WSGI SPARQL entry point, > > filesystem-to-graph-tools etc. (Both of which I have some code; and I > > believe e.g. Chimezie also has a SPARQL-endpoint (CherryPy-based).). > > > > I believe I mentioned thinking about this earlier this year. Still, I > > think it would be great if you want to be its creator though, among > > other reasons for the more "official air" of it. Still, is there a > > reason not to have it in the same repo as RDFLib itself? It could for > > instance ease any future move of some parts into the core; and of > > course to allow the same users as for RDFLib itself. (Apart from that, > > a google code repo would do fine too.) > > > > Some ideas to boot: > > > > .. It is nice that setuptools provide the means to automatically add > > command line tools (the 'console_scripts' entry point) - as you have > > already set it up. Apart from the current conversion tool, we could > > then add e.g. a sparql tool and some kind of validator. > > > > .. For an example of what I mean with "filesystem-to-graph" stuff, see > > <http://oort.googlecode.com/svn/trunk/oort/util/graphs.py>. > > > > Best regards, > > Niklas > > > > > > On 6/13/07, Daniel Krech <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > > > As of the last release we included an rdflib_tools top level package to > > > start gathering some unreleased tools people had around. This was meant to > > > be a temporary place holder until a separate project could be created. Any > > > reason not to split these off as a separate project as planned? Main > > > reason > > > motivating the split now is an issue that was hit with the debian > > > packaging. > > > > > > I remember someone telling me they wanted to create such a project, but > > > don't remember who. Anyone wanting to start and lead such a project? Else > > > I'm willing to create a project at code.google.com that we can move the > > > rdflib_tools bits to. > > > > > > > > > Daniel Krech, http://eikeon.com/ > > > > > > > > > > > > > > > _______________________________________________ > > > Dev mailing list > > > Dev@rdflib.net > > > http://rdflib.net/mailman/listinfo/dev > > > > > > > > _______________________________________________ > > Dev mailing list > > Dev@rdflib.net > > http://rdflib.net/mailman/listinfo/dev > > > _______________________________________________ Dev mailing list Dev@rdflib.net http://rdflib.net/mailman/listinfo/dev