On 25 Apr, 2013, at 15:58, Daniel Holth <dholth at gmail.com> wrote:
> 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.
I wouldn't mind a PEP 390 update when the 2.0 metadata format is done
that limits it explicitly to distutils (and possibly setuptools), with the
express purpose of making it possible to use a setup.cfg with a minimal
setup.py file when using a new enough distutils version.
In particular, a python distribution without extensions shouldn't require
anything beyond this:
from distutils.core import setup
setup()
This would make it easier to teach (GUI) tools, like IDLE, to maintain
the input data used by distutils because they won't have to try to
parse and update Python code.
Using PEP 390 beyond distutils/setuptools isn't useful, there is no need
to restrict other tools in this way as long as they can generate output
in the right format (wheel and sdist archives).
>> 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.
Funnily, I tend to use ini files a lot at $work because the are good
enough for simple configuration and power-users/admins with a windows
background are more likely to understand them then json or (shudder) xml
files.
>> 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
I use something simular in a number of my packages, with a single setup.py
file shared between them and all metadata in setup.cfg.
Ronald
>> (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> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org>http://mail.python.org/mailman/listinfo/distutils-sig