On October 29, 2015 at 3:23:34 PM, Brett Cannon (br...@python.org) wrote: > On Thu, 29 Oct 2015 at 12:03 Donald Stufft wrote: > > > On October 29, 2015 at 2:54:19 PM, Daniel Holth (dho...@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. > > > > > > > > > > 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.
My thoughts are basically: * Defining the standard commands has benefits for the current ecosystem as well as the future (much like why PEP 503 defined the /simple/ interface even though I plan to make a new one in the future). * We can always add the build-with key at a later point because adding things is much much easier than removing things so I think being conservative and taking smaller steps is better than taking medium steps. > > > > > > 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). > > > > Well, it kind of is a standard thanks to Paul and zipapp: > https://docs.python.org/3/library/zipapp.html#module-zipapp I’m not sure I follow… Where is the setuptools entry point there? I only see the foo.bar:Whatever syntax, which isn’t what I meant, I meant the actual feature of setuptools entry points which you need to use something like pkg_resources to fetch. > > > > > > ----------------- > > 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 > > > ----------------- 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
