On 3 Aug 2013 06:01, "PJ Eby" <p...@telecommunity.com> wrote: > > On Fri, Aug 2, 2013 at 11:27 AM, Nick Coghlan <ncogh...@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. Cheers, Nick.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
