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

[Donald Stufft]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140515/1214af07/attachment.sig>