Thoughts on language-level configuration support?

[jfager]

On Mar 30, 9:31 pm, "Rhodri James" <rho... at wildebst.demon.co.uk>
wrote:
> On Mon, 30 Mar 2009 16:59:12 +0100, jfager <jfa... at gmail.com> wrote:
> > It's the configuration problem.  Right now you would use something
> > like ConfigParser or optparse to populate some configuration object,
> > which you would then pass around and extract values from.  This would
> > provide two advantages over these approaches:  it would separate "what
> > can be configured" from "the mechanism by which it is configured" -
> > i.e., I, programmer, don't have to make a decision about what the end
> > user has to do to give me those values.
>
> This would be a interesting idea, but ultimately no more than a veneer
> over the current set of configuration possibilities.  Quite how such a
> system would tell whether to get configuration data from command line
> parameters, a config file somewhere, or just pull bytes off the Z-wave
>  from Mars, I'm not at all clear.

Not a veneer over; a foundation under.  As I acknowledged in my blog
post, this would require a small bit of bootstrapping, to configure
which end-user configuration system was used.  But this would simply
point to an adapter, that would map from the desired configuration
interface into the canonical standard api provided by the language
system.

The problem with the current set of configuration possibilities is
that there's nothing really constant between them, unless the
programmer explicitly codes it, even though they're basically
accomplishing the same thing.  There's nothing amazingly special about
this proposal, it's just saying:  that basic thing that we do in a lot
of different ways, let's make as much of that as possible standard.  I
think that cutoff point is below the end-user interface, since there
are a lot of valid ways to want to actually inject config data
(command line, local files, from a db, etc.), but there's no reason
that the end-user interfaces can't rest on top of a lower-level common
format that the programmer can rely on.



> >  And it would allow the
> > configurable surface of the program to be discoverable; I wouldn't
> > have to poke through code or documentation that was maintained
> > separate from the source code.
>
> Except that you still do.  

No, you don't.  If you do, then this proposal hasn't been implemented
(and the little code snippet I provided in my post, please don't
consider that a full implementation, it was just a sketch I threw
together in a really short time).  I'm not saying discoverability
magically arises; I'm saying that it's one the main points that would
be deliberately put into place.


> You've just specified a different way in
> which you have to do this, one that's a good deal less visible in
> the code

Why would it be less visible?  If it's syntax, you would know exactly
where it was just by looking.  I would argue that it's more clear - no
more boilerplate code spent shuffling around config objects that you
peel values out of, just write the code that does the work you're
actually trying to accomplish, with a small bit of syntax to mark that
the end user can provide an alternate value.


> and a lot less self-documenting because it's spread out all
> over the place.  

Actually, you get the best of both worlds.  You get to see clearly in
the code how the configured values are actually used, and you get the
gathered summary of configurable values from the "discoverability"
implementation.


> It also has the major disadvantage from my point of
> view of requiring Python to do magic in the background to figure out
> just what is being configured.

If it's built into the language, it stops being magic, and turns into
"how it works".


- Jason



>
> --
> Rhodri James *-* Wildebeeste Herder to the Masses