+1... I think it would go a long way to stabilizing development here. Most
everything is called in by plugin anyway.
The one thing I haven't figured out with setuptools is how to manage
overrides for plugins (like... I want to use a custom etree xml writer
instead of the one there).
Paste manages this via configuration and the fact that every wsgi app has a
specific execution point to read in configuration.
One idea would be to have defaults exist in a mutable data structure so one
could simple override them::
>>> from rdflib.core import config
>>> config.set_default('rdflib.ep_group', 'package_with_desired_ep')
Obviously, if you have lots of defaults you want to rework, digesting an ini
would make more sense, but I think this would cover most cases on import.
-w
On 9/14/07, Niklas Lindström <[EMAIL PROTECTED]> 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? 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
> - for:
> syntax
> backends
> query engines (probably also possible to dispatch directly
> to backend impls)
>
> * RDFLibBackends
> - all of mysql, bsddb, redland etc.
> - or even split into embedded and relational or similar?
> - registered as plugins using the setuptools/egg mechanism
>
> * RDFLibSparql
>
> One reason is to make it more pluggable and lightweight, and also to
> keep the core of RDFLib in pure python.
>
> 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).
>
> The pluggable architecture could if possible not *depend* on
> setuptools, but use it if available. So the internal plugin registry
> can be the same as today (used by setuptools if there or perhaps by
> "manual" glue code if not..). Though practically it could be easier to
> accept the setuptools dependency and "egg orientation" -- and I
> suspect the namespace mechanism requires it.. (Note that the rdflib
> namespace would be for project-owned code only (the "partitioned"
> rdflib); 3rd party stuff can use the entry-point mechanism but should
> have their own top-level package names.)
>
> 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..
>
> Best regards,
> Niklas
> _______________________________________________
> Dev mailing list
> Dev@rdflib.net
> http://rdflib.net/mailman/listinfo/dev
>
--
| david "whit" morriss
|
| contact :: http://public.xdi.org/=whit
"If you don't know where you are,
you don't know anything at all"
Dr. Edgar Spencer, Ph.D., 1995
"I like to write code like
other ppl like to tune their
cars or 10kW hifi equipment..."
Christian Heimes, 2004
_______________________________________________
Dev mailing list
Dev@rdflib.net
http://rdflib.net/mailman/listinfo/dev
