-
Notifications
You must be signed in to change notification settings - Fork 2k
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 CLI by adding add new click types for fees, amounts, addresses and bytes32 #15718
base: main
Are you sure you want to change the base?
Conversation
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
52186b1
to
4c7317e
Compare
Conflicts have been resolved. A maintainer will review the pull request shortly. |
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 appreciate this integration with Click. I think the new classes should have unit tests though.
4c7317e
to
1ff5910
Compare
1ff5910
to
cf6c0fc
Compare
Failure. Coverage is below 100%.Diff Coverage
|
this only tests the new types class, and the missing lines in in param funcs are expected, as the mojos part isn't user available yet. |
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.
looks good. Could you expand a bit on why you need the isinstance
in the convert functions? it looks risky. If it's just for the default value, would it work yo change the type to the default value to str
to look just like what would be passed on the command line?
It would make sense to hold off landing this until we have test coverage, right?
|
In my mind this increases overall coverage by centralizing where everything is converted, but we can hold it off if you want those other tests first. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
also remove validate fee callback from wallet
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 repeat a detailed review yet. Let's address the existing open issues then go back over the whole thing.
Co-authored-by: Kyle Altendorf <sda@fstab.net>
|
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.
looks reasonable. except it looks like that block of code in validate_uint64()
could be removed
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.
Looks like a couple still open conversations to finish with.
just meant to comment, not approve. sorry
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.
previous approval was meant to be a comment
the cmd test on windows failed twice in a row (with what looks like a time out). I would expect all of these tests to be 100% deterministic, and not be flaky. |
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.
alrighty, this covers the param types and the test file for them. i'll try to get to the rest of the files, but expect them to be a lot less interesting.
try: | ||
d_value = Decimal(value) | ||
except InvalidOperation: | ||
fail_func("Value must be a valid uint64 number", param, ctx) |
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.
uint64
isn't the proper description here. Should also have the actual failure probably, as noted elsewhere.
) -> Decimal: | ||
try: | ||
d_value = Decimal(value) | ||
except InvalidOperation: # won't ever be value error because of the fee limit check |
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.
This comment doesn't seem applicable.
except InvalidOperation: # won't ever be value error because of the fee limit check | |
except InvalidOperation: |
fail_func("Value must be decimal dotted value in XCH (e.g. 0.00005)", param, ctx) | ||
if d_value.is_signed(): | ||
fail_func("Value can not be negative", param, ctx) | ||
if not d_value.is_zero() and d_value < Decimal("0.000000000001"): |
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.
This still allows, for example, 0.0000000000015
which isn't valid. Unless there is a specific feature for this, we might have to multiply by whatever-our-xch-mojo-conversion-constant is then .to_integral()
and compare.
Alternatively, we delete this conversion function and just multiply by the xch-mojo conversion when needed and then use the validate-uint64. The caveat being that ... iirc, balances can be uint128 but coin amounts can only be uint64. So maybe there's a relevant detail there.
A Click parameter type for transaction fees, which can be specified in XCH or mojos. | ||
""" | ||
|
||
name: str = uint64.__name__ # output type |
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.
Technically these are all ClassVar
s such as name: ClassVar[str]
. Probably the same across all these classes.
A Click parameter type for transaction fees, which can be specified in XCH or mojos. | ||
""" | ||
|
||
name: str = uint64.__name__ # output type |
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.
Aside from the hinting, I'm not sure this is right. I did suggest uint64.__name__
instead of "uint64"
since it seemed to be the intent to be tied to the Python type we convert to. But, I'm not entirely sure that we want that as the name.
https://click.palletsprojects.com/en/8.1.x/api/#click.ParamType.name
the descriptive name of this type
Maybe we should figure out where this is used so we can make sure we have useful text there. Or maybe uint64
still ends up sufficiently useful depending.
Or, we can just keep this in mind for later consideration.
from chia.util.config import load_config | ||
from chia.util.default_root import DEFAULT_ROOT_PATH |
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 there a need for these to not be global scope imports?
if hrp == expected_prefix: | ||
addr_type = AddressType.XCH | ||
else: | ||
self.fail(f"Unexpected Address Prefix: {hrp}, are you sure its for the right network?", param, ctx) | ||
else: | ||
addr_type = AddressType(hrp) |
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.
Feel free to close this after reading.
It feels like this pattern belongs on the AddressType
class. The 'to hrp' helper already takes a config so depending on that wouldn't be an issue. It should probably also provide the xch/txch options in some way. An idea for another time.
# TODO: Test MOJO Logic When Implemented | ||
|
||
# Test Decimal / XCH | ||
assert TransactionFeeParamType().convert("0.5", None, None) == uint64(int(0.5 * units["chia"])) |
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.
assert TransactionFeeParamType().convert("0.5", None, None) == uint64(int(0.5 * units["chia"])) | |
assert TransactionFeeParamType().convert("0.5", None, None) == uint64(Decimal("0.5") * units["chia"]) |
AmountParamType().convert("-0.6", None, None) | ||
# Test Type Failures | ||
with pytest.raises(BadParameter): | ||
AmountParamType().convert(float(0.01), None, None) |
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.
AmountParamType().convert(float(0.01), None, None) | |
AmountParamType().convert(0.01, None, None) |
AmountParamType().convert(float(0.01), None, None) | ||
|
||
# Test CliAmount Class | ||
assert decimal_cli_amount.convert_amount(units["chia"]) == uint64(int(5.25 * units["chia"])) |
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.
assert decimal_cli_amount.convert_amount(units["chia"]) == uint64(int(5.25 * units["chia"])) | |
assert decimal_cli_amount.convert_amount(units["chia"]) == uint64(Decimal("5.25") * units["chia"]) |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
1 similar comment
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Lets discuss this again with #16802 |
Purpose:
TransactionFeeParamType
for automatic fee conversionCliAmount
class andAmountParamType
for easy conversion between units.CliAddress
class andAddressParamType
for easy bech32m address conversion and wallet type trackingBytes32ParamType
for automatic str to bytes32 conversion.Merge requirements:
Some light testing of the --mojos argument(Moved to future PR)Current Behavior:
No Breaking Changes, just lots of backend changes.
New Behavior:
N/A
Testing Notes:
This PR has unit tests for the new types, and actual cli tests are coming in #15718