[Distutils] refining the idea of entrypoints and their metadata

[P.J. Eby]

At 11:24 PM 1/11/2010 +0100, Ronny Pfannschmidt wrote:
>Hi,
>
>while toying with the entrypoint system, i repeatedly ran into the need
>of having additional metadata prior to importing
>
>In Plugins that only handle certain filetypes/extensions/mimetypes might
>profit from the additional metadata (while also defering imports)
>
>The same goes for my library anyvc that needs to know what directories
>to check for, however usually the directory checking is a lot faster
>than doing the imports (and implementing custom lazy importing is pain).
>
>So i propose supporting to store additional metadata along with the
>entrypoints.

Just FYI, there is nothing stopping you from implementing something 
like this with an egg_info writer plugin and a custom setup argument:

   http://peak.telecommunity.com/DevCenter/setuptools#adding-setup-arguments
   http://peak.telecommunity.com/DevCenter/setuptools#adding-new-egg-info-files

You could then use the pkg_resources discovery APIs to find distributions:

    http://peak.telecommunity.com/DevCenter/PkgResources#getting-or-creating-distributions

And then pull out the metadata via the API:

    http://peak.telecommunity.com/DevCenter/PkgResources#imetadataprovider-methods

This is exactly how standard entry points are implemented now, so you 
can use this as a guide.

The i18n support for Chandler uses a similar approach, bundling a 
resources.ini in the egg_info metadata, that lists message catalogs 
and other localization resources included in the relevant 
plugin.  (Chandler plugins can provide translations for strings in 
other Chandler plugins, so that e.g. you can distribute a 
multi-plugin localization plugin.)

(Btw, these comments should not be construed as saying a more 
sophisticated system is a bad idea or anything like that, I'm just 
pointing out that you need not wait for someone else to implement 
this for you, as the hooks to do it on your own are documented and 
ready to use.  And perhaps you can then promote your implementation 
as a defacto or dejure standard.  ;-) )