write config.toml with all defaults & improve config doc #733
write config.toml with all defaults & improve config doc #733
Conversation
Codecov Report
@@ Coverage Diff @@
## config #733 +/- ##
==========================================
- Coverage 57.85% 57.37% -0.49%
==========================================
Files 82 82
Lines 8436 8441 +5
==========================================
- Hits 4881 4843 -38
- Misses 3142 3176 +34
- Partials 413 422 +9 |
| fast_sync = true | ||
| db_backend = "leveldb" | ||
| log_level = "state:info,*:error" | ||
| ##### main base config options ##### |
There was a problem hiding this comment.
ok, this is amazing, but here's my crazy question .... can we get this code autogenerated from the config struct during a build process so we don't have to worry about redundant commentary here and in the structs?? is that a crazy thing to ask for :P
There was a problem hiding this comment.
maybe, in the future? I agree with the sentiment but have noticed that generally autogenerated codestuffs get mangled in one way or another. I'll add notices in the appropriate locations + does this code get updated all that much?
| } | ||
|
|
||
| // XXX: this func should probably be called by cmd/tendermint/commands/init.go | ||
| // alongside the writing of the genesis.json and priv_validator.json |
There was a problem hiding this comment.
thoughts? seems awkward to not have the config.toml be initialized alongside genesis.json and priv_validator.json here
82205d2 to
3a3306f
Compare
9308a03 to
ab4b6ad
Compare
config/toml_test.go
Outdated
| ensureFiles(t, rootDir, "data", "genesis.json", "priv_validator.json") | ||
| } | ||
|
|
||
| const defaultConfigHardcoded = `# This is a TOML config file. |
There was a problem hiding this comment.
does it mean we'll have to change this every time we change the config so the tests could pass?
There was a problem hiding this comment.
can't we generate it on the fly or something?
There was a problem hiding this comment.
it's only used by the test. The actual config is generated on the fly, but then the test would be redundant, no? Could use a strings.Contains instead to check that key elements of the config are present; something like:
var elems = []string{"moniker", "seeds", "proxy_app", "fast_sync", "create_empty_blocks"}
for _, e := range elems {
if !strings.Contains(configFile, e) {
t.Fail()
}
}
There was a problem hiding this comment.
Could use a strings.Contains instead to check that key elements of the config are present
I am in favor of doing this
ab4b6ad to
e96ad49
Compare
|
merging to |

closes #705
links to: #709, #636
Running
tendermint initused to produce the followingconfig.toml:which did not provide all that much information about the many config options. Now, the
config.tomllooks like:and the documentation for the


config.tomlnow shows the full config file, replacing this:with this: