[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