[Distutils] Last PEP 426 update for a while
ncoghlan at gmail.com
Sat Aug 3 05:03:28 CEST 2013
On 3 Aug 2013 06:01, "PJ Eby" <pje at telecommunity.com> wrote:
> 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. ;-)
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:
- 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG