[Distutils] refining the idea of entrypoints and their metadata

Ronny Pfannschmidt Ronny.Pfannschmidt at gmx.de
Tue Jan 12 09:10:45 CET 2010

On Tue, 2010-01-12 at 01:28 -0500, P.J. Eby wrote:
> 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.

This is a good inspiration on getting started.

> 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.  ;-) )

I just wanted discussion first in order to get rid of initial stupid
ideas - and your hint to the extension system was pretty helpfull in
destroying the stupid idea of needing to hack into entrypoint parsing

I'll start to implement my current needs for setuptools/distribute 0.6
and distribute 0.7 and post for peer-review once i get to a acceptable

Regards Ronny

More information about the Distutils-SIG mailing list