On 03/08/2010 15:19, David Cournapeau wrote: > On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou<solipsis at pitrou.net> wrote: > >> On Tue, 03 Aug 2010 10:28:07 +0200 >> "M.-A. Lemburg"<mal at 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 at 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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4