[Distutils] Last PEP 426 update for a while

PJ Eby pje at telecommunity.com
Fri Aug 2 22:01:28 CEST 2013


On Fri, Aug 2, 2013 at 11:27 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I pushed a version of PEP 426 with an initial sketch of an entry
> points replacement design: http://hg.python.org/peps/rev/ea3d93e40e02
>
> To give it a sensible home in the PEP, I ended up defining "modules"
> and "namespaces" fields in addition to "commands" and "exports". The
> overall section is called "Installed interfaces".
>
> I initially tried it with the unpacked multi-field mapping for export
> specifiers, but ended up reverting to something closer to the
> setuptools notation for readability purposes. For the moment,
> "requires_extra" is included since it isn't that hard to explain.

Thanks again for all the hard work in putting this together!

Btw, under setuptools, entry point *group* names are restricted to
valid Python module names, so this is a subset of valid distribution
names.  Conversely, entry *point* names are intentionally arbitrary
and may contain anything that isn't an '=', as long as they don't
start with a '#'.

The reason for these choices is that entry point groups are used to
ensure global uniqueness, but need a standard way for subdividing
namespaces.  (Notice that setuptools has groups like
distutils.setup_arguments and distutils.setup_commands.)

Conversely, individual entry point names have a free-form syntax so
that they can carry additional structured information, like a
converter specifying what it converts from and to, with a quality
metric.  The idea is to allow tools to build plugin registries from
this kind of information without needing to import the modules.
Basically, if you can fit it on one line, before the '=', in a
reasonably human-readable way, and it saves you from having to import
the module in order to figure out whether you wanted to import it in
the first place, you can put it in the name.

You might wish to make names a bit more restrictive than this, I
suppose, but I'm not sure that all of the limitations of distribution
names are actually appropriate here.  In particular, restricting to
alphanumerics, dots, and dashes is *way* too restrictive.  Entry point
names are sometimes used for human-readable command descriptions, e.g.
this is a perfectly valid entry point definition in setuptools:

     wikiup: Upload documents to one or more wiki pages =
some.module:entrypoint [extra1, extra2]

Anyway, entry point group names are definitely *not* recommended to
follow distribution names, as that makes them rather useless.  Things
that consume entry points will generally have more than one group,
eventually, so at least one of those groups will then have to *not* be
named after a distribution, unless you arbitrarily break up the
project into multiple distributions so the group names match, which is
kind of silly.  ;-)

Finally, it might be good to point out once again that extras are not
so much "a set of dependencies that will be checked for at runtime" as
a set of dependencies that are *needed* at runtime.  This need may or
may not be checked, and may or may not be satisfied dynamically at
runtime; it depends on the API in use, and how/whether it is invoked.


More information about the Distutils-SIG mailing list