Improve docs clarity on loading custom checkers - FIXED #7502
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Whilst the docs on testing custom checkers do touch on the fact the module has to be in your load path, there are some restrictions that were not made clear before. Specifically, the init-hook configuration item (which is often used explicitly to change the sys.path) is not automatically sufficient. If the init hook is in a file, but the load-plugins argument is passed in the CLI, then the plugins are loaded before the init-hook has run, and so will not be imported. In this case, the failure can also be silent, so the outcome is a lint that will simply not contain any information from the checker, as opposed to a run that will error. This corner case may merit fixing in a separate PR, that is to be confirmed. Closes #7264
Thanks @DanielNoord for pointing it out.
As per suggestion from @DanielNoord, this makes it clearer that installing the custom module is the recommended way.
Thanks to @DanielNoord Co-authored-by: Daniël van Noord <[email protected]>
This is not the way. Co-authored-by: Daniël van Noord <[email protected]>
Co-authored-by: Daniël van Noord <[email protected]>
This is a much clearer way of explaining what is meant by this recommendation. Co-authored-by: Daniël van Noord <[email protected]>
Thanks to Pierre Sassoulas and Daniel Noord
Pull Request Test Coverage Report for Build 3088428075
💛 - Coveralls |
DanielNoord
requested changes
Sep 20, 2022
doc/whatsnew/fragments/7264.other
Outdated
| @@ -0,0 +1,3 @@ | |||
| Dev documentation is now clearer about custom checker loading. | |||
There was a problem hiding this comment.
I think this can be removed.
Comments thanks to Daniel Noord
DanielNoord
approved these changes
Sep 20, 2022
DanielNoord
added
Documentation 📗
Skip news 🔇
|
Thank you very much for this and all other work related to it @daogilvie 😄 |
|
You are very welcome, thanks for improving and maintaining a project that has saved me from myself more times than I can remember 😂 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NOTE: This PR replaces #7276 due to an admin error on my part.
Type of Changes
Description
Short
This PR just updates the documentation page on writing custom checkers. It adds
information about some restrictions between how
init-hookchanges the loadingpath and when you can use that to import your custom module.
Long (in the commit message)
Whilst the docs on testing custom checkers do touch on the fact the
module has to be in your load path, there are some restrictions that
were not made clear before.
Specifically, the init-hook configuration item (which is often used
explicitly to change the sys.path) is not automatically sufficient. If
the init hook is in a file, but the load-plugins argument is passed in
the CLI, then the plugins are loaded before the init-hook has run, and
so will not be imported. In this case, the failure can also be silent,
so the outcome is a lint that will simply not contain any information
from the checker, as opposed to a run that will error.
This corner case may merit fixing in a separate PR, that is to be
confirmed.
Closes #7264