Re: [Userops] Antonio Terceiro's DebConf talk on packaging free software web applications

[David Thompson]

This environment variable idea is getting a bit out of hand.
Environment variables have their place, specifying search paths for
instance.  However, what is being proposed goes far beyond sanity by
suggesting that it be used as *the* means of configuring applications.

Asheesh Laroia <address@hidden> writes:

> A quick reply; pardon the terseness.
>
> On Tue, Aug 25, 2015 at 11:15 AM, Christopher Allan Webber <
> address@hidden> wrote:
>
>> So I think I'm -1 on environment variables, and here's why:
>>
>>  - I agree that environment variables provide a sense of coherence
>>    that's "already here", and so that's tempting.  But!
>>
>
> OK yay environment variables.

No.

>>
>>  - Environment variables are the POSIX global variable system, and I've
>>    had enough troubles fighting global variables the last few years.
>>    I'd like to not invent new systems to fight them all over again.
>>
>
> They're not "global"; they're passed from one process to another process.
>
> (process 1) ---launches ---> (process 2)
>
> process 2 starts with some environment variables.
>
> If it wants, it can delete them in initialization, so the rest of the code
> in process2 can't see the data in the environment variables.

They are global to the process, and because they are global state you
have to take care to do as you said: Fiddle with that state to avoid
passing on unwanted environment variables to child processes, or else
face a potential security vulnerabilities or other problems.

>>  - Environment variables are an extremely lossy format, being
>>    strings-only.
>>
>
> Meteor, a widely-used web app framework, uses JSON-encoded data in
> environment variables as its config file passing format:
>
> http://docs.meteor.com/#/full/meteor_settings
>
> So we can do that, too, if we really need to.

I really don't think we should aspire to such nasty hacks.  What about
configuration files that are written in actual programming languages?
Should we advocate that people stuff bits of source code into
environment variables?

>>  - The primary goal is a shared state, but what if deploying multiple
>>    applications?  This seems to move back towards the problem of
>>    assuming packages are going to roll out one apache config for a user,
>>    and that's all the user needs is one application.
>>
>
> The primary goal is not "shared state", it's "state passing", which is like
> a function call.

This analogy is inaccurate.  Since environment variables are inherited
by child processes, I would call it dynamic scoping at best.

> It's not "one Apache config for a user", it's "one Apache config per app
> instance." Like Heroku. How does that mean "all the user needs is one
> application?" On Heroku, with is environment-variable based, you can have N
> applications.
>
>
>>
>>    Okay, you might say, we'll just swap out the environment variables
>>    every time we launch an application!  This is still tricky when it
>>    comes to, say, an application that is dependent upon connections to
>>    two separate postgres daemons, which you might imagine are now
>>    expecting environment-based configuration.
>>
>
> Can you say more about how this is a problem? I don't really understand,
> and the Heroku world already seems to solve this fine.
>
>
>>
>>  - It seems to me that a good system is a combination of reflection
>>    upward towards a user interface for configuration, and then back down
>>    again *through composition*.
>>
>
> Reflection up and down is a giant API surface. Start simple and see if you
> need something large.
>
> I'm proposing the use of environment variables effectively as
> keyword-arguments in a Python-style function call.

Except these keyword arguments (environment variables) are extremely
limited.  Every application has to parse the values, validate them,
check if any have been forgotten, handle default values, etc.  They
already have a configuration file for you to be doing this in!

I think it is a huge mistake to lower configuration data to a lowly
string stuffed into a process-global environment variable.  Data is
code, and code is data.  You wouldn't want to evaluate code this way, so
why should we treat our data so poorly?  We should be building systems
that give us the expressive power to parameterize and compose
configurations in an extensible way.  Environment variables are simply
to clunky and weak to do this job well.

-- 
David Thompson
GPG Key: 0FF1D807