[Distutils] PEP 426: proposed change to extension fields + entry points

Daniel Holth dholth at gmail.com
Mon Feb 25 15:38:32 CET 2013


I'm probably the only one but I'm not a fan of JSON with all the extra "
marks compared to the venerable, lovely, flatter and much easier to edit
Key: value format. The METADATA file needs to represent Name, Version, and
Requirements and the rest is fluff that no one will ever use. It's very
healthy to put other kinds of metadata in different files in the .dist-info
directory (no need to bump the metadata version number) and our package
indices can learn how to index those too.

For entry-points it would be more than sufficient to say "this package
defines console_scripts and gui_scripts" and put the details elsewhere.

On Mon, Feb 25, 2013 at 9:19 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> I've decided I'm really not happy with the current approach to
> extension fields in PEP 426. It's ugly, clunky, inflexible and is hard
> to cleanly convert to more structured metadata.
>
> Here's the current example from the PEP:
>
>     Extension: Chili
>     Chili/Type: Poblano
>     Chili/Heat: Mild
>
> Here's what I'm thinking of changing it to:
>
>     Extension: Chili
>     Chili/json: {
>         "type": "Poblano",
>         "heat": "Mild"
>     }
>
> So rather than allowing *arbitrary* additional headers as it does now,
> an Extension declaration would allow only one new header:
> <extension-name>/json
> That would then allow arbitrary embedded JSON (so long as you still
> follow the "no blank lines, because that 's the end of the headers"
> rule)
>
> When converting the entire metadata definition to JSON for subsequent
> processing, the extensions fields would then cleanly convert from
> multiple extension entries to something like:
>
>     "extensions": {
>         "Chili": {
>             "type": "Poblano",
>             "heat": "Mild"
>         }
>     }
>
> The other area where I think such an "embedded JSON" approach could
> work is coming up with a clean format for an Entry-Points field.
> Specifically, I am thinking of proposing the setuptools.setup
> inspired:
>
>     Entry-Points: {
>         "console_scripts": {
>             "foo": "my_package.some_module:main_func",
>             "bar": "other_module:some_func"
>         },
>         "gui_scripts": {
>             "baz": "my_package_gui.start_func"
>         }
>     }
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130225/4d6d1901/attachment.html>


More information about the Distutils-SIG mailing list