feat: add an `env_file` configuration option to load environment variables from a file

[xpepper]

Proposal: Support for Loading Environment Variables from External Files

In some cases, specifying environment variables directly in the bacon.toml file can be suboptimal or inconvenient:

• You may need to set a large number of environment variables, which could clutter the bacon.toml file.
• You might already have a .env file or similar configuration containing those variables, and duplicating them in bacon.toml would lead to redundancy and potential sync issues.
• Your .env file may contain sensitive values that you do not want to commit to version control, while the bacon.toml file is meant to be shared across the team and tracked in the repository.

To address these scenarios, I'm proposing the addition of a new env_file configuration option. This option allows users to load multiple environment variables from a file, as an alternative to specifying them individually using the existing env key.

There are a few edge cases we may want to clarify through discussion—for example, how to handle conflicts if a variable is defined both in env and in the external file referenced by env_file.

I’ve opened a PR to serve as a starting point for discussing the feature's usefulness and implementation details: 🔗 https://github.com/Canop/bacon/pull/374

Looking forward to your feedback and thoughts! 🙏

[Canop]

The upsides you listed are real.

But there are downsides too:

• this is a new configuration format for bacon, and one which isn't well normalized
• .env files most often support variable expansion, which isn't the case here, having large env files without expansion is rare
• you usually expect to source env files or use other shell related facilities

Opinions from other users welcome.

[xpepper]

Thanks for the feedback @Canop!

I totally understand your concerns, let me try to address them briefly:

“This is a new configuration format for bacon, and one which isn't well normalized.”

I agree that keeping configuration formats simple and coherent is important. To me, the env_file proposal tries to stay minimal... it just points to a plain text file of KEY=VALUE lines. I'm not entirely sure what “well normalized” refers to here, but I'm definitely in favor of evolving the format cautiously and only adding complexity as new use cases emerge.

“.env files most often support variable expansion, which isn't the case here, having large env files without expansion is rare.”

That’s a great point. Supporting variable expansion could certainly improve compatibility with existing .env setups. Still, my suggestion would be to start with a simpler implementation (no expansion for now) and consider adding it later if the need proves common enough.

“You usually expect to source env files or use other shell related facilities.”

Absolutely. It’s true that tools like direnv or shell source commands can solve this. But I like the idea that bacon can help standardize things across a team without requiring everyone to install or configure external tools.

That said, I’m totally open to other approaches if there’s a better way to address the use case (e.g., many env vars, shared team config, minimal duplication). My main goal here is to improve the workflow without increasing friction.

Thanks again for the feedback! 🙏