On Sep 14, 2007, at 8:23 AM, Niklas Lindström wrote: > Hi Daniel, all! > > This -- problems with compiling -- reminds me of a task I've been > thinking about for a while but haven't got time to fully elaborate on. > > How do you feel about modularizing RDFLib into a couple of eggs?
+1 > Using > the namespace mechanism of setuptools, this can be quite convenient. > Zope 3 is a good example of a successful practise, as is e.g. the > partition of Paste. > > I just paste my non-finsished suggestion here as a food for thought: > > * RDFLibCore > - perhaps using entry points for registering added (and 3rd party) > plugins using the setuptools/egg mechanism I just had a case where I had declared rdflib as a dependency for a Pylons app for a customer. I had to back off it because the production deployment box has no compiler toolchain to compile the SPARQL parser (I assume that's what it is), which sucks, because this app doesn't *use* anything other than a simple, in-memory ConjunctiveGraph instance. > And this not only to make it installable without compilation, but also > to faciliate use with Jython, IronPython and other python ports (with > possible backends like Jena et al). Also, having separate packages > could make development smoother (running tests, refactoring etc). It would also allow a more flexible release and milestone schedule. The core should be frozen for a long time, and other stuff could proceed orthogonally, not requiring constant updates, etc. > Does this sound interesting or too far-fetched from a practical > perspective? I *believe* it can be done without a gargantuan effort. > (I don't know what impact it will have on e.g. the debian rdflib > package and similar though..) It is perhaps a thing for RDFLib 3.. Doing this would alone justify a major version bump, IMO. Cheers, Kendall _______________________________________________ Dev mailing list Dev@rdflib.net http://rdflib.net/mailman/listinfo/dev
