On October 29, 2015 at 2:54:19 PM, Daniel Holth (dholth@gmail.com) wrote:
> I think that would be very handy, especially making setuptools not a
> special case. You could get it down to 3 lines in setup.cfg, a file that
> already exists and already gathers random settings.
>
> <snip>
I don’t think we should try to use an entry point (at least not yet). One of the key points is to minimize the conceptual churn and to move forward slowly while still progressing. I don’t think that using a class really buys us much because anyone who is capable of writing that class is also capable of writing a small CLI interface to be used within a setup.py. It feels more like churn for churn’s sake than anything else and some sort of idealogical purity over pragmatism.
There is also the familiarity of standardizing the CLI that pip will use when calling setup.py.
The one thing that Daniel's case 3 proposal has over Donald's, though, is that all data can be self-contained in setup.cfg. If a build tool chooses to have the user specify all data in setup.cfg then you just copy-and-paste the `[bootstrap]` part and then in some other section they specify the info the build tool wants. Donald's approach could do something similar but it also requires copying around a boilerplate setup.py that is never modified. It's a familiarity vs. simplicity issue.
Personally I still like the simple setup.py approach for the familiarity of it as well as the backwards-compatibility/transition bit being so simple with older versions of setuptools.
I also don’t want to base any standard on setuptools entry points because they are not a standard (and if we did, the key should not mention pip at all, pip shouldn’t be special cased any more than setuptools should).
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig