On Thu, Jul 18, 2013 at 9:27 AM, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 18 July 2013 14:03, Daniel Holth <dho...@gmail.com> wrote:
>>
>> Abstract
>>
>> This PEP proposes a way to represent the setuptools “entry points”
>> feature in standard Python metadata. Entry points are a useful
>> mechanism for advertising or discovering plugins or other exported
>> functionality without having to depend on the module namespace. Since
>> the feature is used by many existing Python distributions and not
>> everyone wants to use setuptools, it is useful to have a way to
>> represent the functionality that is not tied to setuptools itself.
>
>
> 1. I think that console (and GUI) scripts should be top-level metadata, not
> an extension. Installers need to be able to create wrappers based on these,
> and it is useful data for introspection.
It is an extension so it can be a separate PEP, since there's enough
to talk about in the main PEP. The document tries to write down what
setuptools does in a straightforward json way.
> 2. distlib calls these "exports" and I think that's a better name. But if
> names are all that we argue over, I'm happy :-)
>
> 3. Someone (I think it was PJE) pointed out that having entry points in a
> separate metadata file was good because it allowed a fast check of "does
> this distribution expose entry points?" Note that this isn't a useful thing
> to check for script wrappers, which again argues that those should be
> handled separately.
I am more interested in seeing the installer update some kind of index
like a sqlite database. I don't know if it would be faster since I
haven't tried it.
> 4. You seem to have an extra set of curly braces in a few places. You say
> the value of "entry_points" is a dictionary, but you show it as a set
> containing one dictionary in the set (and of course sets aren't valid JSON).
> I'll assume this is just a typo, and you meant
>
> { …
> “extensions”: {
> “entry_points” : {
> “sqlalchemy.dialects” : [ “mysql = sqlalchemy_mysql:base.dialect”] ,
> ...
> }
> }
> }
>
> 5. What's the logic for having the values (I don't see a good term for these
> - the "mysql = ..." bit above) be a structured string that the user has to
> parse? Either it should be completely free format (which I suspect makes it
> of limited use for introspection, if nothing else) or it should be broken up
> into JSON - no point in having a blob of data that needs parsing in the
> middle of an already structured format!
For one thing you can have more than one mysql = in the same
sqlalchemy.dialects. I think in this instance the string parsing is
probably simpler than defining a more JSONy version.
FWIW the PEP 426 metadata is also full of structured strings.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
