As Drumkit is a tool for scaffolding web projects and working with other tools, anyone who will be writing make targets for Drumkit will need to understand what kinds of things you can/cannot and should/should not do with the
In summary, the golden rules for
.env files are:
.envfile must never be committed to a repo.
.envfile should never contain more than one line with a particular variable name.
.envfile are visible to all software and containers in that application.
… these will be discussed in more detail below.
.envfile like Drupal’s
settings.phpbut for other apps.
.envto store config/secrets, other programs you or other developers use might automatically import variables from them and/or change their behaviour based on environment variables imported by other layers in the stack:
Consequently, expect the
.env file to not exist or be empty when your target is run.
.env file format doesn’t have an official spec; the behaviour when two lines try to define the same variable differs based on the parser:
Consequently, blindly appending lines to the
.env file (e.g.: with a shell script’s
>> pipe redirection operator) is very likely to lead to unexpected behaviour.
Note that the
dotenv-linter/dotenv-linter project provides validation, fixing, and comparison tools for
Also note that some developers use direnv to automatically load variables into their current environment.
It’s reasonable to expect that a project will need its own way to compile its
.env file to fit its particular stack of software, in the same way it’s reasonable to expect that a project will need to define its own
install steps to fit its particular stack of software.
Put another way, let a project define it’s own
.env: make target in
drumkit/mk.d/; so in Drumkit itself, if you’re writing make targets to add/modify a
.env file, prefix the make target names appropriately so they don’t collide.