> Of course you can also use the re-exec feature of make to write a rule to generate the include file then you have the full power of a recipe.

I like the idea, especially because of the re-exec feature. However, my goal was to avoid having to make this external to make. Also given that the rule for recipe is not likely to change from project to project, I would like to suggest an alternative (and possibly simpler) abstraction:

What if we have a special target rule, which has dependencies on any number of ".env" files:

.ENVFILES: .env production.env

This will have the job of parsing the env files and including them into make.

> I'm also not sure I agree that the right behaviour is to always export every variable in the file. But these are details:...

I suggested the always export option because that's usually the way I've seen .env files being used.

For example, when working with docker-compose yaml files, docker-compose reads a .env file and any other included yaml files can also see the variables. See the syntax rules for .env

The same is true for most people who use .env files with shell scripts. Some will do something like this to automatically export and load the variables into the current process:

set -a; source .env; set +a

Pipenv which is used to manage a python project dependencies will also usually load the .env file into the current process, and every program that is started sees the environments.

In any case, I don't think lack of automatic export is a deal breaker. If the current plan is to create an external program, or to use the special target, then decision to export or not can be made later rather than now.

No, no, that's not something one should expect from a .env file.

I said that some dotenv parsers take it a step further to do all that fancy interpolation, but really .env files are just files containing a bunch of key=value lines, no functions or shell parsing necessary. It's just a configuration file. Variable interpolation is a nice-to-have feature of most dotenv parsers, not a requirement.

---

Unfortulately I don't think there is a definite spec I can point to, but I found this one which explains the format. And another one which talks about the origin

To bring this back on topic, I believe "make" already has the capacity to do what most dotenv parsers are doing. As you can see from the stackexchange page I linked earlier, make can already read some simple .env files when included using the "include" directive, but for others it just needs to be guided a little. For example:

TEST_VAR='8X46Yj*aek3GQeiW7#bK!Eg@#6vjV'

should be translated into

export TEST_VAR := 8X46Yj*aek3GQeiW7\#bK!Eg@\#6vjV

And something like:

EMAIL=${USER}@example.org

is to be translated to

export EMAIL := $(USER)@example.org

So the goal is not to write a parser, but more of a translator that converts .env syntax to make syntax.

This feature can be exposed either via a directive within a Makefile (includeenv) or a flag (--envfile) to make.

Hi Paul

.env files are commonly used for specifying secrets for an application or a build.

Please see this question to get an idea of how people are currently trying to use .env files in their Makefile:
https://unix.stackexchange.com/questions/235223/makefile-include-env-file

The format of a .env file is simply "key=value". From the make.env project I linked to, here is what a typical file may look like

APP_PASSWORD='8oyy!r#vNpRy2TT'
FOO_BAR='4dabfs#a%d73w$Z2TBN4!nYD4Y$TW'
TEST_VAR='8X46Yj*aek3GQeiW7#bK!Eg@#6vjV'
ANOTHER_VAR='"hello world'

---

In the above case, the single quotes surrounding the value are to be ignored, but everything else is to be taken literally. Some .env parsers take it a step further and also expand environment variables within the .env file, so values that are surrounded by double quotes and have $ symbol inside are expanded and the result is what is stored as part of the value. ex. user="$USER" expands to user="username".

The solution I settled on for the make.env project is to convert each of those lines to "export KEY:='$(value VALUE)'", then load them into make using the --eval flag. This was the only way I found that reliably loads the value into make without make attempting to interpret the value.

I hope that clears things up

I would like the ability to allow make to read .env files. I kinda already got started here with a python wrapper around make, called `make.env`: https://github.com/smac89/make.env

I believe this is something many people will benefit from, and it can be exposed via a flag of some sort.

I don't mind working on it, but I just need to know if it's something that has been considered before and discarded, or if there are any concerns with giving `make` the ability to read environment files