-
Notifications
You must be signed in to change notification settings - Fork 224
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
additional validation for cli arguments #3894
additional validation for cli arguments #3894
Conversation
2534ba7
to
4f7e473
Compare
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.
Thanks @ltalirz , few comments and suggestions
|
||
|
||
class IdentifierParamType(click.ParamType, ABC): | ||
class IdentifierParamType(AlphanumericStringType, ABC): |
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 don't think we can make this change. It is true that for the ID
and UUID
interpretation of the IdentifierParamType
the alpha-numeric rules apply, however, the LABEL
is currently not restricted to this. By changing this people will no longer be able to load certain entities through their label that contain non-alpha-numeric character
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.
Right, consider this more of a "draft" PR (somehow I always realize too late when something is a draft PR and I think one cannot change it afterwards).
I wanted to discuss what the validation of labels should be - both on a global level and for specific labels (computers, codes, ...).
ecfd32e
to
f209092
Compare
c59c32f
to
cca6522
Compare
09a2508
to
a58739e
Compare
Codecov Report
@@ Coverage Diff @@
## develop #3894 +/- ##
========================================
Coverage 78.20% 78.20%
========================================
Files 460 460
Lines 33982 34027 +45
========================================
+ Hits 26574 26611 +37
- Misses 7408 7416 +8
Continue to review full report at Codecov.
|
@sphuber I think this is ready for review now. See the description of the PR for the list of changes. |
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.
Thanks @ltalirz . Only two comments: the first one is really minor and I only put it there since I though you would anyway have to do a few more touchups, but it seems all is good. There is just one question about making the ProfileParamType
validation more strict, which could cause (light) problems for existing profiles. Just wanted to check if you had thought about this
.github/config/profile.yaml
Outdated
@@ -1,6 +1,6 @@ | |||
--- | |||
profile: PLACEHOLDER_PROFILE | |||
email: aiida@localhost |
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.
Not crucial, but since we decided to keep this as allowed, maybe revert it
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.
Done!
|
||
|
||
class ProfileParamType(click.ParamType): | ||
class ProfileParamType(LabelStringType): |
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.
Here we are making the rules more strict. There might be profiles out there that don't respect the rules of LabelStringType
. Those will no longer be able to be used in the CLI. Of course, the profile name can easily be adapted manually in the config.json
, just wanted to check if you thought about this. If you are ok with doing this, then also fine by me
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'm aware, but I think this change is still reasonable. My arguments:
- as you say, it's something that can be easily fixed (and it's probably in the best interest of people to do so)
- it can prevent issues during profile setup, which is the first thing new aiida users do
- the profile name is not exported, so this does not invalidate any published data
* Start validating * hostnames * emails * entry point names * InteractiveOption: validate empty reply The `InteractiveOption` of the CLI always allowed users to pass `!` in order to avoid setting a value, bypassing any further validation that may be provided by the `type`. Change this behavior such that entering `!` results in an empty string being passed further to the `type`. Only if conversion by the type passes as well should a `None` value be returned. * increase code reuse in options * move IdentifierParamType back to how it was before * add test for verdi code duplicate return empty string, if passing `!` into string-type parameters.
with outputting test coverage to the terminal on travis, the test output becomes increasingly unreadable and it becomes difficult to find the information on failing tests (which is what one is usually looking for). * remove coverage information from test output on travis * limit printing of test timings to 50 longest-running tests
860d3b0
to
cb55197
Compare
cb55197
to
f5b4aa7
Compare
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.
Thanks a lot @ltalirz
fixes #3301
fixes #3596
fixes #3897
fixes #3770
labels (Improved input validation ofverdi computer setup
#3596)aiida@localhost
)!
: TheInteractiveOption
of the CLI always allowed users to pass!
in order to avoid setting a value, bypassing any further validation that may be provided by thetype
. Change this behavior such that entering!
results in an empty string being passed further to thetype
. Only if conversion by the type passes as well should aNone
value be returned.verdi setup
docs for authentication via Unix socketsNote: Since existing databases may contain data that does not validate under the new rules, we have not introduced validations for CLI options that would make it impossible to work with existing data (e.g. for the
label
of nodes, etc.).Those should be made in a separate PR.
Todo: