-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
refactor: allow getting address prefix from address codec #15913
Changes from all commits
a54ed2a
c63dec0
2aa75a8
ab09d08
ca61ef7
01bc9a9
7e4f580
02ae046
50931b5
271a70e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
We can't assume the codec is always bech32. I'd rather find another way to deal with this
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.
Yes (#15913 (comment)), so do you find this naming not fitting if the address has no prefix?
I do not know if you've seen the autocli PR but this come handy there.
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.
Is that fine for autocli to depend directly on auth then?
Personally, I don't like it, but that would solve the issue I have there.
Another way I thought would be autocli to depend on auth config, but this was still less clean than with this PR.
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.
since autocli is built off of grpc why not use
cosmos-sdk/proto/cosmos/auth/v1beta1/query.proto
Line 64 in be081b1
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.
It is almost what it already uses there, and it works fine for hubl, which will build the command after having queried an endpoint. However, for normal commands, like
simd
,gaiad
, etc.. When we enrich the root command, we have no endpoint to query. The information is however available, and imho this was the cleanest way to get it.We could however:
config.Bech32Prefix
for the address prefix, which is fine for app wiring app, but it makes it weird when you have to construct AppOptions manuallyI am open to other suggestions however.
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.
Why don't we just change the flag.Builder argument to take address.Codec instead of bech32 prefix. I think that would resolve this without needing to change address.Codec. Also if we do need the actual prefix let's use an extension interface instead of changing address.Codec
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 didn't think of the problem this way. This would indeed work too, and only complexify the flag builder
I will close this then and re-open it shortly with only the clean-ups that were done here.
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.
While we can't assume this, this is pretty baked into the SDK and I personally can't see this changing in the future.