[Distutils] moving things forward

Alex Grönholm alex.gronholm at nextday.fi
Thu May 5 16:34:38 EDT 2016


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
> 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/6f9906f1/attachment-0001.html>


More information about the Distutils-SIG mailing list