Contributing#

Finding something to do#

Want to contribute to pylint? There's a lot of things you can do. Here's a list of links you can check depending on what you want to do:

If you are a pylint maintainer there's also:

Creating a pull request#

Got a change for Pylint? Below are a few steps you should take to make sure your patch gets accepted:

  • You must use at least Python 3.8 for development of Pylint as it gives you access to the latest ast parser and some pre-commit hooks do not support python 3.7.

  • Install the dev dependencies, see Contributor installation.

  • Use our test suite and write new tests, see Testing pylint.

  • Document your change, if it is a non-trivial one:

    • A maintainer might label the issue skip-news if the change does not need to be in the changelog.

    • Otherwise, create a news fragment with towncrier create <IssueNumber>.<type> which will be included in the changelog. <type> can be one of the types defined in ./towncrier.toml. If necessary you can write details or offer examples on how the new change is supposed to work.

    • Generating the doc is done with tox -e docs

  • Send a pull request from GitHub (see About pull requests for more insight about this topic).

  • Write comprehensive commit messages and/or a good description of what the PR does. Relate your change to an issue in the tracker if such an issue exists (see Closing issues via commit messages of the GitHub documentation for more information on this)

  • Keep the change small, separate the consensual changes from the opinionated one.

    • Don't hesitate to open multiple PRs if the change requires it. If your review is so big it requires to actually plan and allocate time to review, it's more likely that it's going to go stale.

    • Maintainers might have multiple 5 to 10 minutes review windows per day, Say while waiting for their teapot to boil, or for their partner to recover from their hilarious nerdy joke, but only one full hour review time per week, if at all.

  • If you used multiple emails or multiple names when contributing, add your mails and preferred name in the script/.contributors_aliases.json file.

Tips for Getting Started with Pylint Development#

  • Read the Technical Reference. It gives a short walk through of the pylint codebase and will help you identify where you will need to make changes for what you are trying to implement.

  • astroid.extract_node is your friend. Most checkers are AST based, so you will likely need to interact with astroid. A short example of how to use astroid.extract_node is given here.

  • When fixing a bug for a specific check, search the code for the warning message to find where the warning is raised, and therefore where the logic for that code exists.

  • When adding a new checker class you can use the get_unused_message_id_category.py script in ./script to get a message id that is not used by any of the other checkers.

Building the documentation#

You can use the makefile in the doc directory with make html to build the documentation. To test smaller changes you can consider build-html, which skips some checks but will be faster:

$ cd doc
$ make install-dependencies
$ make build-html

We're reusing generated files for speed, use make clean when you want to start from scratch.

How to choose the target version ?#

Choose depending on the kind of change you're doing:

  • In patch release (1.2.3), we only fix false positives and crashes.

  • In minor releases (1.2.0), we add checks, remove checks, drop python interpreters past end of life, upgrade astroid minor/major versions and fix false negatives.

  • In major releases (1.0.0) we change everything else (pylint options, json output, dev API...) while still trying to minimize disruption.