[Distutils] moving things forward

Thu May 5 17:05:29 EDT 2016

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 
> <mailto: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
>>     <mailto: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 <mailto:Chris.Barker at noaa.gov>
>>
>>
>>     _______________________________________________
>>     Distutils-SIG maillist  -Distutils-SIG at python.org <mailto:Distutils-SIG at python.org>
>>     https://mail.python.org/mailman/listinfo/distutils-sig
>     _______________________________________________
>     Distutils-SIG maillist  - Distutils-SIG at python.org
>     <mailto: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/2d1ac64e/attachment-0001.html>