[Distutils] Simplify 426: Deprecate Author-email and Maintainer-email

Daniel Holth dholth at gmail.com
Thu Apr 25 15:58:13 CEST 2013


I would prefer to see PEP 390 withdrawn and I think this has been
suggested before. The metadata is already sourced from different files
depending on your build system.

The .ini format and our parsers for it are really awful. I always
resented having to learn it in order to use distutils/setuptools when
every other language (RFC822, Python, JSON) is both better and already
familiar.

FWIW bdist_wheel does something half-PEP-390 inspired with setup.cfg:

[metadata]
provides-extra =
    tool
    signatures
    faster-signatures
requires-dist =
    distribute (>= 0.6.34)
    argparse; python_version == '2.6'
    keyring; extra == 'signatures'
    dirspec; sys.platform != 'win32' and extra == 'signatures'
    ed25519ll; extra == 'faster-signatures'
license-file = LICENSE.txt

(https://bitbucket.org/dholth/wheel/src/tip/setup.cfg?at=default)


On Thu, Apr 25, 2013 at 8:30 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> Nick Coghlan <ncoghlan <at> gmail.com> writes:
>
>> splitting them is the right way to go, and also that a multi-file
>> input format is likely a better option than trying to cram everything
>> into one file.
>
> There are areas of overlap, if you consider "archiver", "builder" and
> "installer" roles. For example, the source files and in-package data are
> needed by both builder and archiver. The beauty of JSON is that it allows you
> to have your cake and eat it, to an extent. For example, if you consider that
> inputs to the different roles are dicts, it's not a big deal if you have a
> higher-level dict which contains the others as sub-dicts. So I don't see a
> big issue with having one file as long as the schema is clearly defined so
> that a specific role could pull out the relevant stuff.
>
> Also note that in the PEP 397 implementation (dictConfig) there is already
> the ability to have cross-references to shared sections in a dict serialised
> as JSON, so there's no need to compromise on DRY even when there are data
> overlaps.
>
> I've added some support for dict-based configuration in distlib (a backport
> of the generic configuration stuff from 2.7/3.2 dictConfig, to support 2.6)
> but the use of that's not yet documented.
>
> Regards,
>
> Vinay Sajip
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


More information about the Distutils-SIG mailing list