[Distutils] setup_requires for dev environments

[Donald Stufft]

> On Mar 16, 2015, at 11:24 AM, Daniel Holth <dholth at gmail.com> wrote:
> 
> We could support this syntax right now. It's so simple. Don't deride
> it as a pseudo standard, turn it into an actual standard and praise it
> as something practical that will not take years to implement. Then
> after those years have passed and the new PEP actually works and has a
> distutils replacement to drive it, deprecate the old standard.
> 
> If you can come up with something better that can ship before 2016, by
> all means.
> 
> [metadata]
> setup-requires = cffi
>    pip
>    pycparser >= 2.10
> 
> 
> 
> https://bitbucket.org/dholth/setup-requires

It is a psuedo standard unless it is backed by a defined standard. That's not
a derision, it's just a fact.

The first step is to determine *what* the problem is that it's actually
attempting to solve. That's not clear to me currently other than some vague
statements about pain, but what pain? What's actually occuring and how does
this address those problems?

After figuring out what the actual problem is, we can look at the proposed
solution and see how well it actually solves that problem, if there is maybe
a better solution to the problem, and if the benefits outweigh the costs or
not.

The ease of implementation is not the only factor in deciding if something is
a good idea or not. We have to take into account forwards and backwards
compatiblity. If we implement it and people start to depend on it then it's
something that's going to have to exist forever, and any new installer is going
to have to replicate that behavior. If people don't depend on it then
implementing it was a waste of time and effort.

For instance, if the problem is "when setuptools does the install, then things
get installed differently, with different options, SSL certs, proxies, etc"
then I think a better solution is that pip does terrible hacks in order to
forcibly take control of setup_requires from setuptools and installs them into
a temporary directory (or something like that). That is something that would
require no changes on the part of authors or people installing software, and
is backwards compatible with everything that's already been published using
setup_requires. That's the primary problem that I'm aware of.

If I try and guess at other problems people might be solving, one might be
that in order to use setup_requires you have to delay your imports until after
the setup_requires get processed. This typically means you do things like
imports inside of functions that get called as part of the setup.py
build/install process. This isn't the most fun way to write software, however
it works. Specifying the setup_requires in a static location outside would
enable pip to then install those things into a temporary directory prior to
executing the setup.py which then lets you do imports and other related work
at the module scope of the setup.py. This particular problem I'm not sure it's
worth fixing with a stop gap solution. It would require breaking the entire
existing install base of installation tools if anyone actually took advantage
of this fact, which I don't think is generally worth it to have slightly nicer
use of things in your setup.py (essentially allowing you to import at the top
level and not require subclassing command classes).

So yea, what's the actual problem that this is attempting to solve?

---
Donald Stufft
PGP: 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/20150316/3d8d2fb3/attachment.sig>