Adding config variables via run-app-docker-opts

[stuartpb]

This was touched on in #4: Heroku adds config variables "before" executing the contents of .profile.d.

This would remove most of the point of the release step (which still needs to exist because of stuff like the way plushu-addons defines linked container variables), and would replace the app-env hook (unless plushu-release-env were to defer to --env options, which would break the aforementioned plushu-addons).

[stuartpb]

Considering how app-env works (ie. for addons it expands the Docker link environment variables), this would need a little more thought (so "app-env" would need to be split into "app-env" and "app-profile", with a plugin that could dump "app-env" into "app-profile" as an alternative to one that adds "app-env" as "--env" options).

[stuartpb]

So plushu-release-env would become plushu-release-app-profile and would have to be used in conjunction with either plushu-app-env-in-profile or plushu-app-env-docker-opts.

[stuartpb]

Actually, I think I'll deprecate the app-env altogether in favor of plushu-app-env-docker-opts, which will read the app's environment from the config directory rather than a hook (#4).

So basically, everything that isn't config will change to use the app-profile hook, plushu-release-env will be renamed to plushu-release-app-profile, and there will be a new plugin (plushu-app-env-docker-opts) that will apply config when running local apps.

Actually, I'll keep the app-env hook between config and app-env-docker-opts, just with the understanding that anything that isn't providing basic key-value arguments should be using app-profile instead. (The meta-variable plugin would then still use app-env.)

[stuartpb]

Now, the question is, is there a simple way to interpolate -e options between incoming variables without deserializing and re-serializing? I'm considering making it a codified fact that every line of app-env is an environment variable, which would make it as simple as inserting "-e" at the beginning of every line (which is trivial).

[stuartpb]

Except, nuts, xargs doesn't deserialize $'bash'-type strings, which is what printf %q outputs when its input has newlines. So changing app-env to not involve shell interpolation means there needs to be a better mechanism for serializing these - I'm afraid that'll be printf "'"; sed "s/'/'\\''/g" "$FILENAME"; printf "'". And, unless the signature of app-env changes, that'll have to happen again for the conversion to run-app-docker-opts.

So... I'm thinking there might be a new "sentinel value" argument to app-env signaling that environment var pairings should be prefixed with "-e ".

[stuartpb]

Alternately, app-env could convert to backslash-escaped-whitespace read syntax, which is compatible with xargs, follows existing hook precedent, and is fairly simple to process with sed iirc

while read pair; do
  printf '-e '
  sed 's/\s/\\\0/g' <<<"$pair"
  printf '\n'
done

Or maybe the sed+herestring part could even be done in-shell, or in awk (entirely in awk?).

[stuartpb]

Anyway, I guess the future of app-env kind of depends on #4 as well as this, since the current serialization format is very profile-specific.

Either way, what needs to happen now is #6.