Matt Solomon

Yea I want someone to be able to clone a repo, configure a `.env` file, and have `forge test` run with those environment variables which get loaded because they're used...

You could argue hardhat does allow for this: In `hardhat.config.ts` you can access env vars like normal with `process.env.MY_ENV_VAR`. So a common approach is something like this: - Commit a...

Ahh interesting! Let me make sure I'm understanding: Since every param in `foundry.toml` can also be set with `FOUNDRY_PARAM_NAME`, you're suggestion the way to use env vars would be define...

Makes sense. Maybe a good solution to mitigate items 1 and 2 is adding a field to the config file called something like `env-vars=['FOUNDRY_FORK_URL', 'FOUNDRY_FORK_BLOCK']`, and foundry auto-loads those env...

Personally I like that approach, though I know above @onbjerg mentioned he didn't love the idea of non-standard TOML, but I do think it provides the best and simplest UX....

@mattsse Did https://github.com/foundry-rs/foundry/pull/2334 add general support for this, or only for certain config keys?

Mainly anywhere you might have API keys, which would also include `eth_rpc_url` and `etherscan_api_key`. But more generally, it feels inconsistent to only support this in one section or only for...

Heh thought that might be the answer. IMO best practice is to have a committed `.env.template` type of file committed to a repo so devs know which env vars they...

IMO yes, this would be a really great feature. Having a module for etherscan compilation would also be useful for things like https://github.com/foundry-rs/foundry/pull/2494#issuecomment-1198773042

Ah good point, it would be nice to support contract-level skips too, but `contract SkipMyContract` would be a new naming approach + seems more likely to clash with a real...