Actual behaviour
rad config set suggests that a value was set, although it wasn't. Running e.g.
$ rad config set 'preferredSeeds[0]' "z6MkrLMMsiPWUcNPHcRajuMi9mDfYckSoJyPwwnknocNYPm7@iris.radicle.xyz:8776"
z6MkrLMMsiPWUcNPHcRajuMi9mDfYckSoJyPwwnknocNYPm7@iris.radicle.xyz:8776
results in an unchanged config file:
{
"publicExplorer": "https://app.radicle.xyz/nodes/$host/$rid$path",
"preferredSeeds": [],
"web": {
"pinned": {
"repositories": []
}
},
...
Expected behaviour
rad config set should print an error if no value was set.
rad config set shouldn't even work like that lol! As far as I know, it won't dig into the object. Could you open your file manually and check if you have a key called preferredSeeds[0] now? Hahaha
Oh my, I didn't realize...I tried this jq-style syntax at some in the past already (independent from the OP on Zulip) because that felt natural to me.
I think it's fine to leave the current behavior then, but maybe add some examples to the rad config --help. WDYT?
It just came to my mind that we should also print the key, so users will at least see what key they've set.
Ya, examples would be a great addition. I think printing the new key and value would also be great.
A stretch goal would be to parse a key ensuring that people don't use [] syntax, however, that does mean we restrict the types of keys that could be used – which could be arguably be a bad experience if someone wanted to add new keys of that form.
Are then custom config keys supported?
I ran rad config set dupa aaaa and got
confised when rad config didnt show it
anywhere, even though rad config get dupa
worked fine.
I checked on current master caee776c388ffac2ea55cc9d1e3d7fa108ca6df5