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

Asheesh Laroia asheesh at sandstorm.io
Tue Aug 25 15:18:43 EDT 2015

A quick reply; pardon the terseness.

On Tue, Aug 25, 2015 at 11:15 AM, Christopher Allan Webber <
cwebber at dustycloud.org> 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:


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

>    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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mediagoblin.org/pipermail/userops/attachments/20150825/46ecb60e/attachment.html>

More information about the Userops mailing list