Pub build/serve/run does not support defining environment variables

[DartBot]

This issue was originally filed by @butlermatt

---

Currently dart2js supports -D option to define environment variables. See Seth's blog post:

http://blog.sethladd.com/2013/12/compile-time-dead-code-elimination-with.html

Currently pub build will not accept (let alone pass) -D arguments to dart2js.

[munificent]

Yeah, this would be good to support.

Might also be nice to be able to specify these in the pubspec.

---

Removed Type-Defect label.
Added Type-Enhancement, Triaged labels.

[anders-sandholm]

Added Area-Pub label.

[munificent]

Removed Priority-Unassigned label.
Added Priority-Medium label.

[nex3]

I'm not a big fan of the ability to define arbitrary environment variables in the pubspec. It seems out-of-scope. Users have the means to define their environment variables via the OS; if a variable is specific to a project and not to a user's configuration, it's not really an environment variable anyway.

If the use case for this is just passing flags to dart2js, this should be merged into issue #14664.

[munificent]

Users have the means to define their environment variables via the OS

These "environment variables" are an entirely unrelated concept to the OS's environment variables. They're a way of passing in constants to Dart code from outside. See:

https://api.dartlang.org/docs/channels/stable/latest/dart_core/bool.html#fromEnvironment
https://api.dartlang.org/docs/channels/stable/latest/dart_core/int.html#fromEnvironment
https://api.dartlang.org/docs/channels/stable/latest/dart_core/String.html#fromEnvironment

They are passed to the command-line VM using "-D<name> <value>" (I think? I'm not aware of any actual documentation of this feature).

[munificent]

Pub build and pub serve are currently focused on web applications. Dartium does not support these "environment variables" yet, so we'd be unable to support this in pub serve. Given that, we won't support it in pub build yet because that would lead to diverging behavior between the app in development and in production.

Once Dartium supports this, we can look into figuring out how we want to pass this along to it.

---

Marked this as being blocked by #15925.

[nex3]

These "environment variables" are an entirely unrelated concept to the OS's environment variables. They're a way of passing in constants to Dart code from outside.

Ugh, "environment variable" is not a good name for that concept. Now we have two notions of "environment variable" that refer to completely separate ways of passing in constants to Dart code from outside.

[munificent]

Issue #16370 has been merged into this issue.

[sethladd]

Added Pub-Build label.

[sethladd]

Here's the use case:

We have a build process. We compile our app with dart2js. We set environment variable for the VERSION, via -DVERSION=1.2.3

dart2js correctly "bakes" in that VERSION value into the compiled code.

pub build is the "canonical" way to build a Dart app. However, we can't pass in the environment variable via pub build tool via command line. Often times, the build step is part of a larger workflow, driven by a script. We don't want to physically edit the pubspec.yaml file in the build workflow when we change this VERSION, we'd like to set these values from the command line.

---

cc @johnmccutchan.

[DartBot]

This comment was originally written by @zoechi

---

I think a very simple solution to all these "configurable pubspec.yaml" issues would be to add support for reading the pubspec.yaml file from stdin.

This would allow all kind of solutions

• just passing a pubspec.yaml like pub xxx < pubspec_release.yaml
• using shell scripts (awk/sed) cat pubspec.yaml | somescript | pub xxx
• from a Dart script that processes a pubspec.yaml template and feeds the result into the pub instance started by the script (for example by using Grinder).

An ugly workaround is to rename the pubspec.yaml, save a customized file as pubspec.yaml, run pub xxx and then restore the original pubspec.yaml.

[DartBot]

This comment was originally written by @paulevans

---

or... you know pub could just pass on the environment to the transformers it runs :)
I cannot even get Seth's debug example to work via pub build / serve:
http://blog.sethladd.com/2013/12/compile-time-dead-code-elimination-with.html

[nex3]

Passing in an entire pubspec via stdin seems vastly like overkill, especially since you need to make sure that it has everything else identical to the current pubspec. At that point you might as well just write a script to temporarily modify the existing pubspec.

[DartBot]

This comment was originally written by @zoechi

---

It allows a lot of flexibility without adding much complexity to pub.
Temporaily modifying pubspec.yaml is IMHO much more error-prone (file permissions, concurrent file access, restore default file in case of an error, ...).

I don't see why this should be overkill. It would be simple to use a few $xxx and do shell string interpolation or similar.
I also can't imagine pubspec.yaml to grow to a size where this approach might cause problems.

[sethladd]

Related conversation on Twitter: https://twitter.com/paulecoyote/status/590892034900131840

This blog post talks about String.fromEnvironment() but this technique doesn't work with pub build: http://blog.sethladd.com/2013/12/compile-time-dead-code-elimination-with.html