- Change the order in which the environment variables from the .env f…

[leobm]

Thanks, nice project, can use it well myself right now.
But I have extended your project a bit. Maybe you can use it too. What do you say to my changes?

• Change the order how the environment variables from the .env file merged with the OS environment variables.
  Variables from the .env file can override OS environment variables.

• Add the possibility within the .env file to refer to variables within the .env file or to replace the placeholder variable with the value from the OS environment variable.

[fgm]

Interesting, thanks for the ideas. These are two distinct changes:

• swapping the overriding order: for my own use cases, overriding a file with an envvar is the typical need, but I can imagine the need being the reverse, e.g. when running with a fixed environment in different directories. I would not make it the default, but how about placing it behind a flag ?
• interpreting variables: now that one is intriguing. It makes the most sense in the overriding order you suggest, but actually has a related version by default with the $(foo:-default} syntax. Since this is not part of the usual features of .env files, I'm more perplexed about that one. Have to think more about it.

In the meantime, if you're ok with putting the overriding reversal behind a flag, we could just merge that first part.

[fgm]

Probably only in verbose mode ?

[fgm]

missing terminal LF

[fgm]

missing terminal LF : looks like an editor configuration issue ; maybe add a .editorconfig for that ?

[fgm]

As mentioned in the general comment, this reverses the overriding logic, so I think it is better to put it behind a CLI flag.

[leobm]

Interesting, thanks for the ideas. These are two distinct changes:

swapping the overriding order: for my own use cases, overriding a file with an envvar is the typical need, but I can imagine the need being the reverse, e.g. when running with a fixed environment in different directories.
I would not make it the default, but how about placing it behind a flag ?

https://www.npmjs.com/package/env-cmd
uses e.g. the --no-override "Do not override existing environment variables" flag for something like this
You could also define an opposite flag "--do-override" or something?

interpreting variables: now that one is intriguing. It makes the most sense in the overriding order you suggest,

The Laravel framework uses exactly this format
.env files, that's why I came up with the idea, because it's really handy. I use something like this often when I work with Laravel.
https://laravel-news.com/using-variables-in-your-env-file
https://blog.quickadminpanel.com/how-to-use-laravel-env-example-files/
Which is probably based on https://github.com/vlucas/phpdotenv where you can also use this format.

Also Docker uses the same format e.g. in the Docker files etc.

but actually has a related version by default with the $(foo:-default} syntax.
Since this is not part of the usual features of .env files, I'm more perplexed about that one. Have to think more about it.

Variables makes sense in several cases

1. to map existing OS environment variables to new names.
2. it is also good if you have a default path that you can then use again and again in other environment variables without having to rewrite the complete path each time.

WORKSPACE_PATH=/www/system/data
COOP_PARTNER1=${WORKSPACE_PATH}/coop1
COOP_PARTNER2=${WORKSPACE_PATH}/coop2

Ok, I haven't thought about default values yet, would be cool of course, so without
defining an additional environment variable.
The idea with ${FOO:- default} I find not so bad or maybe ${FOO|default} ?
Or another idea, you could define private environment variables with the same name, just with a two exclamation mark in front and in top of the .env file?
!!FOO=VALUE

and then if you use ${FOO} somewhere, but when this variable does not exist as OS environment variable, then !!FOO is used? These private variables must then be deleted from the map if they are not used. These variables can only be used within the .env file and are only accessible there.

3. to extend or completely replace existing environment variables e.g.
   PATH=~/dev/bin:${PATH}

In the meantime, if you're ok with putting the overriding reversal behind a flag, we could just merge that first part.

Sure, I don't have a problem with that, I could just imagine that sometimes it can be really useful to overwrite certain environment variables, e.g. for the development environment.

Best,

Felix