Contributing#

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

  • We recommend using Python 3.8 or higher for development of Pylint as it gives you access to the latest ast parser.

  • Install the dev dependencies, see Contributor installation.

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

  • Add an entry to the change log describing the change in doc/whatsnew/2/2.15/index.rst (or doc/whatsnew/2/2.14/full.rst if the change needs backporting in 2.14). If necessary you can write details or offer examples on how the new change is supposed to work.

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

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

  • Write a comprehensive commit message

  • 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)

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

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.