-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Improve docs clarity on loading custom checkers #7276
Improve docs clarity on loading custom checkers #7276
Conversation
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
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 start this note with something like:
The preferred way of making plugins available is by installing them as a package, etc.?
@@ -223,6 +223,18 @@ Now we can debug our checker! | |||
environment variable or by adding the ``my_plugin.py`` | |||
file to the ``pylint/checkers`` directory if running from source. | |||
|
|||
If your pylint config has an init-hook that modifies | |||
``sys.path`` to include the module's parent directory, this | |||
will also work, but only if: |
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.
will also work, but only if: | |
will also work, but only if either: |
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.
Just saw this myself, mortified, good spot thanks @DanielNoord!
Thanks @DanielNoord for pointing it out.
As per suggestion from @DanielNoord, this makes it clearer that installing the custom module is the recommended way.
@DanielNoord thank your for such a quick review! I've updated as per your suggestions, what do you think? |
Pull Request Test Coverage Report for Build 3008066091
π - 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.
Let's wait on the discussion in the issue before merging this. L229-L240 might need to change.
Rest looks good to me! Thanks @daogilvie π
No problem! Thank you for very patiently reviewing my first attempt at a documentation PR π I have some bad habits in terms of brevity and language to unlearn. I'll make the changes above and then, as you say, pause this until after any potential changes in behaviour. |
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]>
Side note: I have made the commits individually in the UI for convenience, as your suggestions made sense to me straight away. Is that something you as maintainers prefer or dislike? Would it be better to have one commit for all recommendations? I didn't seem to have the "add to batch" button available. |
Usually I/We prefer one commit, but it doesn't matter too much. As long as you don't rebase or force push the Github UI is pretty good at showing what changed and what remained the same after new commits.
I know, very annoying. It only shows up in the |
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.
LGTM, thanks a lot !
@daogilvie should we close this ? It seems it would be a valuable addition to the doc ? @DanielNoord why do we have a blocked label ? |
Oh goodness I completely forgot about this. It was blocked pending resolution of the other PR. |
|
||
* the ``init-hook`` and the ``load-plugins`` list are both | ||
defined in a pylintrc file, or... | ||
* the ``init-hook`` is passed as a command-line argument and |
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.
Let's explicitly state what doesn't work
@@ -0,0 +1,3 @@ | |||
Dev documentation is now clearer about custom checker loading. |
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 this needs a fragment. I'll add the skip news
label.
I have just pushed a commit with the review fixes in, but I think my deletion of the previous fork has left this PR in a bad state. @DanielNoord @Pierre-Sassoulas I think I may have to close this PR and re-open a new one from the replacement fork for this to work. Do you mind? |
Not at all, don't hesitate to ping me for a review :) |
Replaced with #7502 |
I don't seem to be able to do this directly (the reviewers section of the PR gives me no options), sorry. |
You can use @Pierre-Sassoulas :) |
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-hook
changes 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