[Distutils] fix setup_requires by allowing it in setup.cfg or a setup_requires.txt

[Daniel Holth]

This is not a hole.

Historically there has been VERY STRONG resistance to any practical,
incremental improvements to packaging. Instead we are expected to come
up with something that is ideal and fully formed. The results is that
packaging is not often improved.

The proposal is just a way to make setup.py work a little better. We
are going to have setup.py forever, but we hope it will not be the
primary way to make new packages. We are going to have lists of
requirements forever. We are going to need setup & build requirements
specifications that actually work. Allowing a list of requirements in
setup.cfg or a text file is a very simple way to move in the right
direction.

On Thu, May 15, 2014 at 1:35 PM, Donald Stufft <donald at stufft.io> wrote:
>
> On May 15, 2014, at 1:21 PM, Daniel Holth <dholth at gmail.com> wrote:
>
>> Glyph has suggested something that I've been wanting to do for a long
>> time. "let me use setup_requires somehow so I can have abstractions in
>> setup.py".
>>
>> setup.py allows you to pass setup_requires = [] to the setup() call.
>> Unfortunately, since setup.py needs setup_requires to be installed
>> before it can run, this feature is crap. It also has the unfortunate
>> side effect of recursively calling easy_install and installing the
>> listed packages even when pip or no installer is being used.
>>
>> Instead, I'd like to allow a list of requirements in setup.cfg:
>>
>> [a section name]
>> setup-requires = somepackage > 4.0
>>   anotherpackage >= 3.2.1
>>
>> As an alternative we could look for a file setup-requires.txt which
>> would be the same as a pip-format requirements file.
>>
>> I prefer doing it in setup.cfg because people are used to that file,
>> and because it only accepts package names and not general pip or
>> easy_install command line arguments.
>>
>> This would be simple and a tremendous boon to anyone considering
>> implementing a setup.py-emulating distutils replacement, or to anyone
>> who just likes abstractions.
>>
>> Metadata 2.0 is not a solution for this problem. It's late, it's more
>> complicated, and for any "legacy" packages setup.py is the thing that
>> generates metadata.json - not something that can only run if you parse
>> a skeletal metadata.json, do what it says, and then overwrite
>> metadata.json when dist_info is called.
>>
>> Daniel
>
> Even though it would bandaid over some pain points I'm against shoehorning this
> into the current specs. It's something we'll have to support *forever*. I think
> it makes sense to take the time to do it right instead of trying to toss more
> hacks and bandaids ontop of all of the existing hacks and bandaids.
>
> The first law of holes says "If you find yourself in a hole, stop digging."
>
> We're in a hole, so please, let's stop digging.
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>