[Python-Dev] PEP 376 proposed changes for basic plugins support

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