<div class="gmail_quote">2012/1/24 Alexis Métaireau <span dir="ltr"><<a href="mailto:alexis@notmyidea.org">alexis@notmyidea.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Entrypoints basically are a plugin system. They are storing information in the metadata and then retrieving them when needing them. The problem with this, as everything when trying to get information from metadata is that we need to parse all the metadata for all the installed distributions. (say O(N)).<br>
</blockquote><div><br></div><div>Note that this is why setuptools doesn't put entry points into PKG-INFO, but instead uses separate metadata files. Thus there is a lower "N" as well as smaller files to parse. ;-)</div>
<div><br></div><div>Entrypoints are also only one type of extension metadata supported by setuptools; there is for example the EggTranslations system built on setuptools metadata system: it allows plugins to provide translations and localized resources for applications, and for other plugins in the same application. And it does this by using a different metadata file, again stored in the installed project's metadata.</div>
<div><br></div><div>Since the new packaging metadata format is still a directory (replacing setuptools' EGG-INFO or .egg-info directories), it seems a reasonable migration path to simply install entry_points.txt and other metadata extensions to that same directory, and provide API to iterate over all the packages that offer a particular metadata file name. Entry points work this way now in setuptools, i.e. they iterate over all eggs containing entry_points metadata, then parse and cache the contents. An API for doing the same sort of thing here seems appropriate. This is still "meta" as Glyph suggests, and allows both setuptools-style entry point plugins, EggTranslations-style plugins, and whatever other sorts of plugin systems people would like. (I believe some other systems exist with this sort of metadata scheme; ISTM that Paster has a metadata format, but I don't know if it's exposed in egg-info metadata like this currently.)</div>
<div><br></div><div>Anyway, if you offer an API for finding packages by metadata file (or even just a per-installed-package object API to query the existence of a metadata file), and for process-level caching of extended metadata for installed packages, that is sufficient for the above systems to work, without needing to bless any particular plugin API per se.</div>
</div>