+1 here too. Anyone want to start a blueprint for this item? https://
blueprints.launchpad.net/rdflib/
--Daniel
On Sep 14, 2007, at 11:48 AM, whit wrote:
+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
Daniel Krech, http://eikeon.com/
_______________________________________________
Dev mailing list
Dev@rdflib.net
http://rdflib.net/mailman/listinfo/dev
