[Distutils] A smaller step towards de-specializing setuptools/distutils

[Donald Stufft]

On October 29, 2015 at 3:23:34 PM, Brett Cannon (brett at 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 (dholth at 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 at python.org
> > https://mail.python.org/mailman/listinfo/distutils-sig
> >
>  

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA