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. 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/archive%40mail-archive.com