-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Pylint fix for invalid TOML config #4720
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
Pylint fix for invalid TOML config #4720
Conversation
Pull Request Test Coverage Report for Build 1456420246
💛 - Coveralls |
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.
Could you add a test with the failing toml, please ? :)
Yes I will do that, I also need to accommodate the other failed case which was |
@Pierre-Sassoulas I added three tests, one for empty list and two more for the other two cases mentioned in #4580 |
tests/test_config.py
Outdated
def test_toml_with_invalid_data_for_imports(tmp_path): | ||
# This would test config with invalid data for imports section | ||
# refer #4580 | ||
config_file = tmp_path / "pyproject.toml" | ||
config_file.write_text( | ||
""" | ||
[tool.pylint."imports"] | ||
preferred-modules = { "a"="b" } | ||
""" | ||
) | ||
with pytest.raises(AttributeError): | ||
check_configuration_file_reader(config_file) | ||
|
||
|
||
def test_toml_with_invalid_data_for_basic(tmp_path): | ||
# This would test config with invalid data for basic section | ||
# refer #4580 | ||
config_file = tmp_path / "pyproject.toml" | ||
config_file.write_text( | ||
""" | ||
[tool.pylint."basic"] | ||
name-group = { "a"="b" } | ||
""" |
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.
Per my other comment these two cases are still crashing.
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.
The tests looks nice, do you need help to fix the use case that is failing ?
I have attempted a fix. |
Yes, it would be great if you help me with this. I have tried few things and they dont seem to be working although the tests pass when I executed locally. |
I think we need to define better what is expected in the I guess the expected configuration for the failing test should be: [tool.pylint]
[tool.pylint."messages control"]
disable = "logging-not-lazy,logging-format-interpolation"
[tool.pylint."master"]
load-plugins = [] (Correct me if I'm wrong, I'm no toml expert. But when using the current conf instead of crashing we should have an error message like:
|
9297688
to
f269c4d
Compare
Thanks @Pierre-Sassoulas I have updated with the configuration you have specified here. I will look more into TOML types since I'm not that familiar with it. |
@Pierre-Sassoulas Could you help me proceed with this ? I'm not able to understand it clearly. |
Hey sorry for the time it took to answer this. It look like the configuration from the toml is not taken into account like before as some integration tests are failing. If I were you I would add unit test on the TOML configuration in order to understand what is going wrong in the integrations tests first. Do not hesitate to ask if there is something specific that is blocking you. |
The current failures which i see through via pipeline details are because of the tests which I added. |
d5b765d
to
946adb2
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.
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.
Change (like previously) looks good! I like how we are now handling most errors while still continuing.
Mostly some comments about the tests.
946adb2
to
9e798d1
Compare
@@ -0,0 +1,7 @@ | |||
# Both disable and load-plugins do not belong in the imports section |
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.
Notice how we do not detect anything here, but we should.
Necessary prior to #4720
Necessary prior to #4720
Necessary prior to #4720
Necessary prior to #4720
700b66b
to
953050d
Compare
Add test for current pyproject.toml issues Add a 'bad-configuration-option-value' message for bad toml configuration We do not catch all the problem in toml because we don't know what is expected so we can't recommend. See pylint-dev#5259 We can detect bad top level option when reading the toml
953050d
to
48bce35
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.
Following #5287 this became a more manageable change, it's ready for review @DanielNoord :)
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 really understand how the new checker works, or at least: how its description fits the single case where it can be emitted in option_manager_mixin
.
if not isinstance(values, dict): | ||
# This class is a mixin the add_message come from the pylinter | ||
self.add_message( # type: ignore | ||
"bad-configuration-option-value", line=0, args=(section, values) |
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 probably overlooking something really obvious, but how does this check whether load-plugins = []
should be in the tools.pylint
section (as one of the tests does)?
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 is nothing directly in the tools.pylint
except header (master, message controls, etc), so at top level, if it's not a dict it can't be right. We know nothing about what to expect in the configuration except that.
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.
Perhaps bad-configuration-section
would be better then? For me option-value
implies there is something wrong with the type of the option value (but that might be just me).
I think such a check (option value types) would be helpful anyway, if we don't already check it, so reserving bad-configuration-option-value
for that checker would be better.
Putting stuff in the wrong section and giving stuff the incorrect type are different mistakes and require different messages. For the the latter we could (for example) also include the expected type in the message.
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 agree, I'm going to change the name and upgrade the tests.
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.
Co-authored-by: Daniël van Noord <[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.
I understand what the message is checking now. I think renaming and rewording the description might help future confusion. Rest looks good to go!
if not isinstance(values, dict): | ||
# This class is a mixin the add_message come from the pylinter | ||
self.add_message( # type: ignore | ||
"bad-configuration-option-value", line=0, args=(section, values) |
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.
Perhaps bad-configuration-section
would be better then? For me option-value
implies there is something wrong with the type of the option value (but that might be just me).
I think such a check (option value types) would be helpful anyway, if we don't already check it, so reserving bad-configuration-option-value
for that checker would be better.
Putting stuff in the wrong section and giving stuff the incorrect type are different mistakes and require different messages. For the the latter we could (for example) also include the expected type in the message.
Co-authored-by: Daniël van Noord <[email protected]>
Steps
doc/whatsnew/<current release.rst>
.Description
This is a fix for handling bad or invalid toml configuration in pyproject.toml
Type of Changes
Related Issue
Closes #4580