♻️ refactor(eest): Migrate env_init to eest make env

[raxhvl]

🗒️ Description

This tiny PR introduces the eest make config command. It would be nice to have this included in the upcoming release; I'd rather not have a dangling module in it.

🔗 Related Issues

Closes #970

✅ Checklist

• All: Set appropriate labels for the changes.
• All: Considered squashing commits to improve commit history.
• All: Added an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• Tests: All converted JSON/YML tests from ethereum/tests have been added to converted-ethereum-tests.txt.
• Tests: A PR with removal of converted JSON/YML tests from ethereum/tests have been opened.
• Tests: Included the type and version of evm t8n tool used to locally execute test cases: e.g., ref with commit hash or geth 1.13.1-stable-3f40e65.
• Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.

[danceratopz]

Thanks @raxhvl! It would def be nice to have this cleaned up in the upcoming release.

I had in mind we'd name this make sub-comand env, i.e.,

uv run eest make env

as I think we're likely to subsequently add a config sub-command that helps users create a user-specific config profile for use within EEST.

Were you anticipating having the env.vaml generation just one step of creating a broader user config profile? Ideas welcome.

Btw, we're suffering from unrelated fails again in the CI - fix in progress.

[raxhvl]

Thanks for flagging this @danceratopz!

I now remember our earlier discussion about the name. eest make env is 🤌.

[danceratopz]

Thanks for the update @raxhvl, just fixed up a couple of other instances in the docs. Otherwise, looks good to me!

[spencer-tb]

LGTM! Nice addition :)

Just one question - was there a reason to opt for env.yaml over .env?
My gut would have said to use .env instead - and load the env vars directly with loadenv() etc

[danceratopz]

Just one question - was there a reason to opt for env.yaml over .env?
My gut would have said to use .env instead - and load the env vars directly with loadenv() etc

A .env normally contains key-value pairs, we're using a yaml file. 🙂

[raxhvl]

My gut would have said to use .env instead - and load the env vars directly with loadenv() etc

.env was my first consideration too.

YAML is preferred over .env primarily because it allows for nested configurations. For example, consider the gentest config:

remote_nodes:
  - name: mainnet_archive
    # Replace with your Ethereum RPC node URL
    node_url: http://example.com/
    # Optional: Headers for RPC requests
    rpc_headers:
      client-secret: <secret>