Follow-up Comment #8, bug #62595 (project make):

> 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.


Reply to this item at:


Message sent via Savannah

Reply via email to