On 3 Aug 2013 06:01, "PJ Eby" <pje@telecommunity.com> wrote:
> On Fri, Aug 2, 2013 at 11:27 AM, Nick Coghlan <ncoghlan@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.  ;-)

This makes sense - I was trying to cut down on the number of different naming schemes we had, but may not have divided things up well.

How about we go with:

Valid dotted names for:
- modules
- namespaces
- module & name portions of export specifiers
- export group names
- extension names

Valid distribution names for:
- script wrappers

Arbitrary strings for export group entries.

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

An unconditional import of an optional dependency counts as a runtime check in my view :)

Agreed that could be clarified in the PEP, though.