Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Config] Remove toml support #676

Open
Mirko-von-Leipzig opened this issue Feb 11, 2025 · 2 comments
Open

[Config] Remove toml support #676

Mirko-von-Leipzig opened this issue Feb 11, 2025 · 2 comments
Assignees
Milestone

Comments

@Mirko-von-Leipzig
Copy link
Contributor

As discussed in #650.

Additional considerations:

  • Namespace/prefix the environment variables - this includes both to miden as well as component.
  • Environment variables should consistent between miden-node start node and miden-node start <component>.

Side refactoring

This is also a good opportunity to refactor the various component crates. They really only expose the component entry-point and nothing else. A simple way to ensure this is to keep everything in lib.rs private and only re-export the entry-point e.g. pub use BlockProducer.

At the moment things are a bit more complex because configuration also lives there. However with the proposed change all configuration should live in the node binary, which is also responsible for converting from config to component structs.

@bobbinth bobbinth added this to the v0.9 milestone Feb 12, 2025
@bobbinth
Copy link
Contributor

Namespace/prefix the environment variables - this includes both to miden as well as component.

Do you mean this should be something like MIDEN_STORE_XXX and MIDEN_BLOCK_PRODUCER_YYY?

@Mirko-von-Leipzig
Copy link
Contributor Author

Namespace/prefix the environment variables - this includes both to miden as well as component.

Do you mean this should be something like MIDEN_STORE_XXX and MIDEN_BLOCK_PRODUCER_YYY?

Yeah. Because we will up with multiple XXX_ENDPOINT for example. Tbh the MIDEN_ prefix is unlikely to be useful but I do worry about collisions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants