On 03/08/2010 15:19, David Cournapeau wrote:
On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou<solip...@pitrou.net> wrote:
On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg"<m...@egenix.com> wrote:
Don't forget system packaging tools like .deb, .rpm, etc., which do not
generally take kindly to updating such things. For better or worse, the
filesystem *is* our "central database" these days.
I don't think that's a problem: the SQLite database would be a cache
like e.g. a font cache or TCSH command cache, not a replacement of
the meta files stored in directories.
Such a database would solve many things at once: faster access to
the meta-data of installed packages, fewer I/O calls during startup,
more flexible ways of doing queries on the meta-data, needed for
introspection and discovery, etc.
If the cache can become stale because of system package management
tools, how do you avoid I/O calls while checking that the database is
fresh enough at startup?
There is a tension between the two approaches: either you want
"auto-discovery", or you want a system with explicit registration and
only the registered plugins would be visible to the system.
Not true. Auto-discovery provides an API for applications to tell users
which plugins are *available* whilst still allowing the app to decide
which are active / enabled. It still leaves full control in the hands of
the application.
It also allows the user / sysadmin to use their standard tools, whether
that be disutils2 or package managers, to install the plugins instead of
requiring ad-hoc approaches like "drop this file in this location".
All the best,
Michael Foord
System-wise, I much prefer the later, and auto-discovery should be
left at the application discretion IMO. A library to deal with this at
the *app* level may be fine. But the current system of loading
packages and co is already complex enough in python that anything that
complexify at the system (interpreter) level sounds like a bad idea.
David
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
