[Distutils] moving things forward

[Daniel Holth]

C extensions, py-modules, ...

On Thu, May 5, 2016, 17:05 Alex Grönholm <alex.gronholm at nextday.fi> wrote:

> OK, so which setup() arguments do we want to leave out of the static
> metadata?
>
>
> 05.05.2016, 23:53, Daniel Holth kirjoitti:
>
> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160505/ea53a93e/attachment.html>