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

[Asheesh Laroia]

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.

 

 - 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.

 

 - 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.

 

 - 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.

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.

 

   (Notice, I do not expect end-users to be doing this composition
   themselves, it's important to notice the reflection upwards as well
   as the passing downwards to determine the user's system.)

Sure -- you could decide to pass lots of keyword arguments (aka environment variables) based on your context. Heroku handles this fine through "heroku addons" that read different sets of environment variables.

 

   It's unfortunate that we have so many configuration format systems
   (which puts some towards system recipe authors), however, the
   benefits of having an application built to run based off of the
   composed configuration as made by very high level user decisions is
   much stronger, and in this case at least you may consider both
   configuration files and program arguments to be the equivalent to a
   function invocation.  It's easy to invoke a function again and again
   with different arguments; in a system where those functions read from
   global variables, things become much trickier.

?

Environment variables are keyword arguments in a function call to a new process. I don't see how they're like global variables yet, but maybe you can explain.

 

 - Patching all applications to become environment variable aware and
   eschew their configuration formats is asking a lot of applications,
   while introducing many new problems.

It's very easy, as terceiro noted on IRC, since PHP apps already have access to the environment. Any app that anyone has ever made run on Heroku knows how to do this, so I would be very surprised if it's "asking a lot", since this work has already been done by web 2.0 hipsters consistently over the past 6 years of Heroku.

 

So... if a new system were to come about that was environment variable
based, I have to feel like I'd be pretty unenthused aobut it.

I hope that I can change your mind!

-- Asheesh.