-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
[clap-v3-utils] Deprecate input validators and add parsers to replace them #33276
[clap-v3-utils] Deprecate input validators and add parsers to replace them #33276
Conversation
Codecov Report
@@ Coverage Diff @@
## master #33276 +/- ##
=========================================
- Coverage 81.9% 81.9% -0.1%
=========================================
Files 798 799 +1
Lines 217100 217328 +228
=========================================
+ Hits 177999 178172 +173
- Misses 39101 39156 +55 |
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.
lgtm now. at least we tried to advertise the deprecation!
let's give @CriesofCarrots a day or so to take a look if she likes
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 couple questions from me! Generally, looks good.
let value = arg.replace('\'', ""); | ||
let mut parts = value.split('/'); | ||
let account = parts.next().unwrap(); | ||
account | ||
.parse::<u32>() | ||
.map_err(|e| format!("Unable to parse derivation, provided: {account}, err: {e}")) | ||
.and_then(|_| { | ||
if let Some(change) = parts.next() { | ||
change.parse::<u32>().map_err(|e| { | ||
format!("Unable to parse derivation, provided: {change}, err: {e}") | ||
}) | ||
} else { | ||
Ok(0) | ||
} | ||
})?; | ||
Ok(arg.to_string()) |
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.
There's a lot of shared logic between the new parsers and the deprecated validators. Is there any value to deduping?
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.
Yeah, the parsers that return a String
type basically run the original validator and then return the argument as string. It would be nice to just invoke the validator directly and return the argument, but this will trigger a deprecation warning...
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 was thinking about moving the shared logic to a helper function that's called from the validator and the parser. But it may not be worth the effort.
This lgtm now! Give me a nudge when CI is green and I'll approve for merge. |
Co-authored-by: Trent Nelson <[email protected]>
Co-authored-by: Trent Nelson <[email protected]>
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.
Problem
In clap-v3, the
Arg::validator
is deprecated and replaced withArg::value_parser
. The idea is that when we validate an argument input, we parse the input any way. If we separate out validation and parsing, then for most arguments, we will be parsing the inputs twice, which could be wasteful.The
solana-clap-v3-utils
as well as the solana cli tools that depend on it still uses the deprecated inputArg::validator
.Summary of Changes
I went through each validation function in
clap-v3-utils
and made analogous parsing functions. I thought I would divide the task up into two separate PRs. I deferred creating parsing functions for validation functions that involve theSignerSource
to a follow-up PR.I tried to break-up the commits into a sequence of steps to make it easier to review as much as possible.
FromStr
via theclap::value_parser!(TYPE)
. This means thatis_pubkey
oris_hash
can be deprecated in favor of the automatic clap parsers. I created tests to demonstrate how this is done.pubkey=signature
type arguments, I create a new typePubkeySignature
with thepubkey
andsignature
components and implementedFromStr
for it. The cli code should be able to callmatches.get_one::<PubkeySignature>(...)
to easily parse this type as shown in the tests.parse_url
andparse_url_or_moniker
, but this is fixed in a future commit below 🙏 . With code refactoring, it was a little bit difficult to amend this commit.UiTokenAmount
andRawTokenAmount
structs (similar to how it is done in token-cli). I grepped all usage ofis_amount
andis_amount_or_all
in the monorepo/spl and pretty in all the places, the amount was assumed to be eitherf64
orALL
, so I made the amount inUiTokenAmount
to bef64
for now, but I can also add an extraUiTokenAmount
variant that holdsu64
as well.clap-v3-utils
that uses the newly deprecated functions to satisfy the CI. I also temporarily removed the deprecation foris_pubkey
validation function since it is used in some validator functions that will be deprecated in a follow-up PR.solana-keygen
to satisfy the CI. Once I clean out the deprecated functions fromsolana-clap-v3-utils
, I will remove the rest of the deprecated components from keygen.input_validators
submodule should really be part ofinput_parsers
submodule. Before moving these parsers, I first refactored theinput_parsers
submodule to prevent it from getting too long. All the parsing functions that involve the signer in some way, I moved it to a separate submodule.input_validators.rs
to theinput_parsers
module.Fixes #