[Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

[Brett Cannon]

The emails seem to have reached an equilibrium point of bikeshedding on the
(bootstrap|setup)_requires issue that is being discussed (as Daniel points
out below, this has nothing to do with how building works and instead is
only about statically declaring what tools need to be installed to simply
run your builder to do whatever the heck it wants; this is the first baby
step to build decoupling/customization).

So who is the BDFL on this decision? It seems we need someone to stop the
bikeshedding on the field name and what file is going to house this
configuration data. And do we need someone to write a PEP for this proposal
to have something to target?

On Thu, 5 May 2016 at 13:54 Daniel Holth <dholth at gmail.com> wrote:

> This is a recurring point of confusion. setup.py is not ever going away.
> In general it is necessary for you to be able to write software to build
> your software, and there is no intention to take that feature away.
>
> People repeatedly come to the conclusion that static metadata means the
> entire build is static. It's only the dependencies that need to be static
> to enable better dependency resolution in pip. The build does not need to
> be static.
>
> The proposed feature means you will be able to have a simpler setup.py or
> no setup.py it by using something like flit or pbr that are configured with
> .cfg or .ini. setup.py is not going away.
>
> Static metadata means the list of dependencies, author name, trove
> classifiers is static. Not the build itself.
>
> Enforced staticness of the build script is right out.
>
> On Thu, May 5, 2016 at 4:34 PM Alex Grönholm <alex.gronholm at nextday.fi>
> wrote:
>
>> I think it would be best to gather a few extreme examples of setup.py
>> files from real world projects and figure out if they can be implemented in
>> a declarative fashion. That at least would help us identify the pain points.
>>
>> For starters, gevent's setup.py looks like it needs a fair bit of custom
>> logic:
>> https://github.com/gevent/gevent/blob/master/setup.py
>>
>> 05.05.2016, 23:30, Chris Barker kirjoitti:
>>
>> On Wed, May 4, 2016 at 7:45 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>
>>> This configuration vs customisation distinction is probably worth
>>> spelling out for folks without a formal software engineering or
>>> computer science background, so:
>>>
>>
>> fair enough -- good to be clear on the terms.
>>
>>
>>> Configuration is different: you're choosing amongst a set of
>>> possibilities that have been constrained in some way, and those
>>> constraints are structurally enforced.
>>
>>
>> That's a key point here -- I guess I'm skeptical that we can have the
>> flexibility we need with a purely configuration-based system -- we probably
>> don't WANT to constrain the options completely. If you think about it,
>> while distutils has it's many, many flaws, what made it possible for it to
>> be as useful as it is, and last as long as it has because is CAN be
>> customized -- users are NOT constrained to the built-in functionality.
>>
>> I suspect the idea of this thread is to keep the API to a build system
>> constrained -- and let the build systems themselves be as customizable as
>> the want to be. And I haven't thought it out carefully, but I have a
>> feeling that we're going to hit a wall that way .. but maybe not.
>>
>>
>>> Usually that enforcement is
>>> handled by making the configuration declarative - it's in some passive
>>> format like an ini file or JSON, and if it gets too repetitive then
>>> you introduce a config generator, rather than making the format itself
>>> more sophisticated.
>>>
>>
>> OK -- that's more or less my thought -- if it's  python that gets run,
>> then you've got your config generator built in -- why not?
>>
>>
>>
>>> The big advantage of configuration over customisation is that you
>>> substantially increase the degrees of freedom in how *consumers* of
>>> that configuration are implemented - no longer do you need a full
>>> Python runtime (or whatever), you just need an ini file parser, or a
>>> JSON decoder, and then you can look at just the bits you care about
>>> for your particular use case and ignore the rest.
>>>
>>
>> Sure -- but do we care? this is about python packaging -- is it too big a
>> burden to say you need python to read the configuration?
>>
>> -CHB
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R            (206) 526-6959   voice
>> 7600 Sand Point Way NE   (206) 526-6329   fax
>> Seattle, WA  98115       (206) 526-6317   main reception
>>
>> Chris.Barker at noaa.gov
>>
>>
>>
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.orghttps://mail.python.org/mailman/listinfo/distutils-sig
>>
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160506/3aeb0aa9/attachment.html>