[Python-Dev] PEP 376 proposed changes for basic plugins support (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Tue Aug 3 16:35:30 CEST 2010

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/

More information about the Python-Dev mailing list