[Distutils] moving things forward (was: wheel including files it shouldn't)

[Nick Coghlan]

On 5 May 2016 at 08:28, Paul Moore <p.f.moore at gmail.com> wrote:
> On 4 May 2016 at 23:11, Chris Barker <chris.barker at noaa.gov> wrote:
>> so it could be purely declarative, but users could also put code in there to
>> customize the configuration on the fly, too.
>
> That basically repeats the mistake that was made with setup.py. We
> explicitly don't want an executable format for specifying build
> configuration.

This configuration vs customisation distinction is probably worth
spelling out for folks without a formal software engineering or
computer science background, so:

Customisation is programming: you're writing plugins in a Turing
complete language (where "Turing complete" is a computer science
classification that says "any program that can be expressed at all,
can be expressed in this language", although it doesn't make any
promises about readability). As such, Python "config files" like
setup.py in distutils and settings.py in Django are actually software
*customisation*  interfaces - the only way to reliably interact with
them is to run them and see what happens. Anything you do via static
analysis rather than code execution is a *heuristic* that may fail on
some code that "works" when executed.

Configuration is different: you're choosing amongst a set of
possibilities that have been constrained in some way, and those
constraints are structurally enforced. 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.

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.

Regards,
Nick.

P.S. Fun fact: XML (as formally specified) is a customisation
language, rather than a configuration language. If you want to safely
use it as a configuration language, you need to use a library like
defusedxml to cut it down to a non-Turing complete subset of the spec.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia