@gleam_env(dev, test, prod) compiler env filter

[inoas]

Similar to MIX_ENV dev/test/prod.

Pass in GLEAM_ENV and certain blocks will be ignored or compiled.

This could be used to add telemetry for production or remove debug logging for production, e.g. the code would in both envs compile without/with those blocks.

maybe something like this

@gleam_env(dev) {
  // debug code here
}

@gleam_env(prod) {
  // telemetry code here
}

@gleam_env(prod, dev) {
  // logger code here
}

[inoas]

More thoughts

• The GLEAM_ENV could be settable via an in gleam.toml and or as an LSP action as well?
• gleam run could default to GLEAM_ENV dev and gleam test to GLEAM_ENV test both overridable from CLI?

[lpil]

Could you give some use cases and examples of how this would be used? Thanks.

[aslilac]

the closest you can get in rust is #[cfg(debug_assertions)], which is by design: if you give people too much access to swap code out between development/test and production builds, they will end up with bugs in productions builds that should've been caught. the condition is named debug_assertions so that you feel like you're misusing it if you try to do anything other than assertions/debugging with it. my gut feeling is that this is too sharp a knife for gleam.

[inoas]

my use case would be debug info existing locally or on stage but not on production.
telemetry that exists only on production
... and removing code entirely

[inoas]

a more generalized form would be

@env(MY_ENV_VAR=dev || MY_ENV_VAR=test) {
  // debug code here
}

[jrstrunk]

This is really similar to using an env package like envoy:

case envoy.get("MY_ENV_VAR") == Ok("dev") {
  True -> {
    // debug code here
  }
  False -> Nil
}

Is having a conditional compilation flag worth avoiding a case statement that reads from the env and an extra dependency?