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

P.J. Eby pje at telecommunity.com
Mon Aug 2 23:31:07 CEST 2010


At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
>If that's the case, then it would be better to come up with an
>idea of how to make access to that meta-data available in a less
>I/O intense way, e.g. by having pip or other package managers update
>a central SQLite database cache of the data found on disk.

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.

Btw, while adding PLUGINS to PEP 376 is a new proposal, it's 
essentially another spelling of the existing entry_points.txt used by 
eggs; it changes the format to csv instead of .ini, and adds 
"description" and "type" fields, but drops requirements information 
and I'm not sure if it can point to arbitrary objects the way 
entry_points.txt can.

Anyway, entry_points.txt has been around enough years in the field 
that the concept itself can't really be called "new" - it's actually 
quite proven.  Checking 
http://nullege.com/codes/search/pkg_resources.iter_entry_points/call 
, I find 187 modules using just that one entry points API.

Some projects do have more than one module loading plugins, but the 
majority of those 187 appear to be different projects.

Note that that's modules *loading plugins*, not plugins being 
provided...  so the total number of PyPI projects using entry points 
in some way is likely much higher, once you add in the plugins that 
these 187 lookups are, well, looking up.




More information about the Python-Dev mailing list