-
Notifications
You must be signed in to change notification settings - Fork 278
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
Add check-keys
option to quoted-strings
rule
#618
Add check-keys
option to quoted-strings
rule
#618
Conversation
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.
Hello Henry, and thanks for this pull request.
I agree with what you wrote in #617 👍
However, I don't see the need for a new rule key-quoted-strings
just for keys, moreover in such a scenario the rule quoted-strings
should then be renamed value-quoted-strings
. In my opinion the required quote type will always be the same (nobody wants '
for keys and "
for values), so what about using quoted-strings
for all quoted strings (whatever their position)? It would also avoid a lot of code duplication.
Please tell me what you think before I look at the code in detail.
PS: You can squash all commits into one for easier review and merging.
docs/conf.py
Outdated
@@ -13,6 +13,7 @@ | |||
|
|||
extensions = [ | |||
'sphinx.ext.autodoc', | |||
'sphinx.ext.autosectionlabel', |
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 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.
In the updated doc strings, I added references to docs for other rules.
For example:
... see the :ref:`quoted-strings` rule ...
This required that section labels be generated by the tooling.
However, since I am going to remove the key-quoted-strings
rule, I will no longer need to reference other rule docs, so this change will not be needed.
I came across a project where they want quotes to be required if there is a I'll pare this PR down to remove the |
2d6ca98
to
16cc4d7
Compare
check-keys
option to quoted-strings
rule
@adrienverge I have updated this for your review. |
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.
Hello Henry, this looks good!
Please see my few requests.
Note: I haven't looked carefully at tests cases yet (see my comment), but at first glance they seem to cover many cases.
yamllint/rules/common.py
Outdated
def is_key(token): | ||
return token and isinstance(token, yaml.KeyToken) |
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 this function is only used at one place, I propose to inline it there. And I believe it's not needed to check token and
because None
can be passed to isinstance()
.
(see my suggestion in the comment below ↓)
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.
👍
yamllint/rules/quoted_strings.py
Outdated
#. With ``quoted-strings: {required: only-when-needed, check-keys: true, | ||
extra-required: ["[:]"]}`` | ||
|
||
the following code snippet would **FAIL**: | ||
:: | ||
|
||
foo:bar: baz | ||
|
||
the following code snippet would **PASS**: | ||
:: | ||
|
||
"foo:bar": baz | ||
|
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.
Neat example 👍
(Can you remove the empty line at the end?)
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.
Sure, but why was there an empty line at the end before I added this example?
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 guess it was introduced by commit 352e1a9, anyway, thanks for fixing it 👍
tests/rules/test_quoted_strings.py
Outdated
def conf(self, options): | ||
conf_with_options = (f"{self.rule_id}:\n" | ||
" check-keys: true\n") | ||
for option in options: | ||
conf_with_options += f" {option}\n" | ||
return conf_with_options |
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.
If I understand correctly this function allows writing:
conf = self.conf(['required: only-when-needed',
'extra-allowed: [^ftp://]',
'extra-required: [^http://]'])
instead:
conf = ('quoted-strings: {check-keys: true\n'
' required: only-when-needed\n'
' extra-allowed: [^ftp://]\n'
' extra-required: [^http://]\n')
If you don't mind I prefer the classic version, because:
- there isn't a big added value in number of lines
- in my opinion it's a bit worse for readability
- the rest of yamllint code uses the classic version.
What do you think?
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.
Sure.
tests/rules/test_quoted_strings.py
Outdated
key_strings = ('---\n' | ||
'true: 2\n' | ||
'123: 3\n' | ||
'foo1: 4\n' | ||
'"foo2": 5\n' | ||
'"false": 6\n' | ||
'"234": 7\n' | ||
'\'bar\': 8\n' | ||
'!!str generic_string: 9\n' | ||
'!!str 456: 10\n' | ||
'!!str "quoted_generic_string": 11\n' | ||
'!!binary binstring: 12\n' | ||
'!!int int_string: 13\n' | ||
'!!bool bool_string: 14\n' | ||
'!!bool "quoted_bool_string": 15\n' | ||
# Sequences and mappings | ||
'? - 16\n' | ||
' - 17\n' | ||
': 18\n' | ||
'[119, 219]: 19\n' | ||
'? a: 20\n' | ||
' "b": 21\n' | ||
': 22\n' | ||
'{a: 123, "b": 223}: 23\n' | ||
# Multiline strings | ||
'? |\n' | ||
' line 1\n' | ||
' line 2\n' | ||
': 27\n' | ||
'? >\n' | ||
' line 1\n' | ||
' line 2\n' | ||
': 31\n' | ||
'?\n' | ||
' line 1\n' | ||
' line 2\n' | ||
': 35\n' | ||
'?\n' | ||
' "line 1\\\n' | ||
' line 2"\n' | ||
': 39\n') |
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 understand you propose to reuse a variable for testing various rule configurations. It is smart, but doing so has already been discussed in other pull requests and was finally rejected, because it makes it hard to read the tests and understand where it should fail / make sure there is no human error. (For instance, it's hard for me to review and visually understand/check test cases.)
I know it's a lot of code duplication, but inside tests we allow it if it helps for readability and maintenance.
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.
No problem. Readability and maintenance are important.
fa17b34
to
9ef0479
Compare
@adrienverge I don't see how the CI errors are related to my change? |
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.
Please ignore the failing tests, they were due to a small bug in pathspec
0.12.0, see cpburnz/python-pathspec#84.
Thanks for your contribution!
Closes #617