[Distutils] refining the idea of entrypoints and their metadata

Ronny Pfannschmidt Ronny.Pfannschmidt at gmx.de
Mon Jan 11 23:24:06 CET 2010


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.

the current data is stored in the form of a ini file a la:
        [group]
        namea = import [extras]
        nameb = import
        [another group]
        ...

Which basically translates to the following data entries per entrypoint:

:group: the group of that entrypoint
:name: the name
:import: the default import
:extras: the setuptools extra dependencies

Now i'd like to add custom entries to that,
and i see various ways to store those

* list of json objects includ (strongly prefered by me)
* adding [group:name] sections right after each group section
  that encode the additional metadata (see examples)


This would allow basic uses like::

        [wiki.renderer]
        creole = foo.bar:CreoleRenderer [creole]
        [wiki.renderer:creole]
        mimetypes: wiki/creole
        fnmaps: *.creole *.wiki
        
or::
        [pygments.lexer]
        Brainfuck = bf:BfLexer
        [pygments.lexer:brainfuck]
        mimetypes: brainfuck?!
        filenames: *.bf *.brainfuck
        aliases: bf

Additionaly the load method of the Entrypoint class could grow a
optional parameter for alternative imports

That would allow listings like::

     [anyvc.backend]
     subversion = anyvc.subversion [subversion]
     mercurial = anyvc.mercurial [mercurial]

        [anyvc.backend:subversion]
        aliases: svn 
        workdir_adm_dir: .svn/
        workdir_has_paths: .svn/entries .svn/props/
        repo_has_paths: format hooks/ db/ conf/ locks/
        workdir: anyvc.subversion.workdir:SubversionWorkdir
        repo: anyvc.subversion.repo:SubversionRepository
        
        [anyvc.backend:mercurial]
        aliases: hg
        workdir_adm_dir: .hg
        workdir_has_paths: .hg/requires .hg/store/
        repo_has_paths: .hg/requires .hg/store/
        workdir: anyvc.mercurial.workdir:HgWorkdir
        repo: anyvc.mercurial.repo:HgRepository

Then one could just choose specific imports by passing the new name of
the import to the load function like::

        workdir_type = ep.load('workdir')
        repo_type = ep.load('repo')
        
As you can see the above is a pretty rough idea and in need of
refinements.

The advantage over just having sets of Entrypoints with group, name,
import is that this metadata extension provides a much more pleasant
entry to medium sized feature and removes the need to import for various
metadata checks (in some of my cases, importing entrypoints completely
dominated the execution times) 

I also played with the idea of having separate entrypoints for metadata
and modules, but there are many cases where that kind of use seems
unpractical or really just unpleasant to me.

An additional item of interest is having multiple Entrypoints which do
the same thing but, are implemented using different dependencies (and i
want them ordered by some kind of preference/priority).
(but i suppose in case of doubt i could implement those as sort by a
metadata key)


Please Discuss!

Regards Ronny





More information about the Distutils-SIG mailing list