-
Notifications
You must be signed in to change notification settings - Fork 385
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
feat: add gnoland config
command suite
#1605
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1605 +/- ##
==========================================
+ Coverage 47.41% 47.50% +0.08%
==========================================
Files 384 388 +4
Lines 61187 61367 +180
==========================================
+ Hits 29014 29152 +138
- Misses 29744 29774 +30
- Partials 2429 2441 +12 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments from the review meeting:
- Preferably let's avoid having all of the flags, and instead having a single source of truth. Approaches can be reflect, codegen, or keeping two registries with a test that checks that the config in tm2 and here doesn't fall out of sync.
- And a preferable API seems to be
gnoland config <key> [<value>]
(or some variation).
Based on these discussions, if we wanted to adapt I've drawn up a small snippet that demonstrates how it would look like (note it always uses the fresh struct, so we can't risk falling out of sync in the update command): Let me know your thoughts, if this looks alright, so I can apply it to this PR 🙏 |
I've swapped the approach in this PR to utilize reflect, as we've discussed: Now, you can edit individual fields (however nested) using a similar syntax to I've also noticed that my previous version of the PR lacked support for the |
@gfanton @ajnavarro |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll make a separate comment for the unmarshaler; mostly nitpicky comments as usual :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a small change needed. I experimented with the command a bit. looks good ! :)
## Description Based on discussions in gnolang#1593, this PR introduces the CLI suite for manipulating the `config.toml`. Using this suite, we can build better workflows for power users. This PR is a series of lego blocks that are required for us to get a normal user chain connection going: - gnolang#1252 - solved `genesis.json` management and manipulation - gnolang#1593 - solved node secrets management and manipulation - this PR - solves `config.toml` management and manipulation All of these PRs get us to a point where the user can run: - `gnoland init` - `gnoland start` to get up and running with any Gno network. The added middle step is fine-tuning the configuration and genesis, but it's worth noting this step is optional. New commands: ```shell gnoland config --help USAGE config <subcommand> [flags] Gno config manipulation suite, for editing base and module configurations SUBCOMMANDS init Initializes the Gno node configuration set Edits the Gno node configuration get Shows the Gno node configuration ``` In short, the `gnoland config init` command initializes a default `config.toml`, while other subcommands allow editing viewing any field in the specific configuration. <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
…1769) After briefly discussing #1605, me and @zivkovicmilos convened that it would be better if the `config` commands took, for the keys in the configuration, their TOML name rather than the internal Go struct field name. This PR implements that.
Description
Based on discussions in #1593, this PR introduces the CLI suite for manipulating the
config.toml
. Using this suite, we can build better workflows for power users.This PR is a series of lego blocks that are required for us to get a normal user chain connection going:
genesis.json
management and manipulationgnoland secrets
command suite #1593 - solved node secrets management and manipulationconfig.toml
management and manipulationAll of these PRs get us to a point where the user can run:
gnoland init
gnoland start
to get up and running with any Gno network. The added middle step is fine-tuning the configuration and genesis, but it's worth noting this step is optional.
New commands:
In short, the
gnoland config init
command initializes a defaultconfig.toml
, while other subcommands allow editingviewing any field in the specific configuration.
Contributors' checklist...
BREAKING CHANGE: xxx
message was included in the description