Add support for env files

[ahochsteger]

I'd suggest the following enhancement of envsubst to be more useful in combination with Docker/Docker Compose or Systemd Unit files:

• Add option to read environment from env files
• Allow multiple env files to be given and process them in order (to override values from former files to support development purposes)
• Add option to ignore the existing shell environment variables and build a fresh environment using the given env file(s)
  This would greatly simplify some development and deployment processes.

[a8m]

Sounds good to me.

Should we follow the the docker-compose syntax rules?

[ahochsteger]

Yes, that makes sense.

[mehdihadeli]

@a8m is this feature in your plan?

[polarathene]

Teller might meet your needs?

• https://github.com/tellerops/teller#whale-easy-docker-environment
• https://github.com/tellerops/teller#white_check_mark-prompts-and-options
• https://github.com/tellerops/teller#scroll-populate-templates

Not quite the same feature set or UX as envsubst offers, although you could technically use them both together.

---

I have given teller a try and looked over the project health. Presently it's got quite a few gotchas if your needs are beyond basic. It can't perform any proper parameter expansion like envsubst can (with it's own share of bugs related to that).

• Add option to read environment from env files

  This is supported. You can pull in all keys from the env file with dotenv provider using the env_sync: property, or you can pull in only a subset of keys with env:. It also supports a feature to rename variables.

  • env_sync uses a remap property to list the original source ENV names as keys, while the values of those keys is the new target ENV name you want to map it to instead.
  • env uses a field property per ENV key listed. It works the other way around though the key is the target ENV to map to, and the field value is the original source name to get the value from.

• Allow multiple env files to be given and process them in order (to override values from former files to support development purposes)

  This is also supported. Your .teller.yaml file can specify multiple providers (and multiple instances of a provider by using a custom name + the kind: <provider here> property). The drawback is providers with the same output keys don't seem to have a consistent ordering, thus you can't have a deterministic layering through a single config/run.

  In your case though, when you only need to choose a different .env file, you can do this with the dotenv provider path property. It can leverage the opts setting to use a variable (only works with path:), and you can populate that via ENV as well as provide a default to fallback to. This way the same provider config is re-used across the different .env files 👍

• Add option to ignore the existing shell environment variables and build a fresh environment using the given env file(s)

  Teller can support this too. It's the default behaviour with teller run. If you need the environment to not be ignored you'd add the carry_env: true setting (does not affect providers).

Useful providers:

• dotenv
• processenv
• filesystem (for assigning an ENV value by reading content of a file)