You think you have found a bug in Pylint? Well, this may be the case since Pylint is under development.
Please take the time to check if it is already in the issue tracker at https://bitbucket.org/logilab/pylint
If you can not find it in the tracker, create a new issue there or discuss your problem on the code-quality@python.org mailing list.
The code-quality mailing list is also a nice place to provide feedback about Pylint, since it is shared with other tools that aim at improving the quality of python code.
Note that if you don’t find something you have expected in Pylint’s issue tracker, it may be because it is an issue with one of its dependencies, namely astroid and logilab-common:
Use the code-quality@python.org mailing list for anything related to Pylint. This is in most cases better than sending an email directly to the author, since others will benefit from the exchange, and you’ll be more likely answered by someone subscribed to the list.
You can subscribe to this mailing list at http://mail.python.org/mailman/listinfo/code-quality
Archives are available at http://mail.python.org/pipermail/code-quality/
Archives before April 2013 are available at http://lists.logilab.org/pipermail/python-projects/
Pylint is developed using the mercurial distributed version control system.
You can clone Pylint and its dependencies from
hg clone https://bitbucket.org/logilab/pylint
hg clone https://bitbucket.org/logilab/astroid
hg clone http://hg.logilab.org/logilab/common
Got a change for Pylint? Below are a few steps you should take to make sure your patch gets accepted.
Test your code
- Pylint keeps a set of unit tests in the /test directory. The test_func.py module uses external files to have some kind of easy functional testing. To get your patch accepted you must write (or change) a test input file in the test/input directory and message file in the test/messages directory. Then run python test_func.py to ensure that your test is green.
- You should also run all the tests to ensure that your change isn’t breaking one.
Add a short entry to the ChangeLog describing the change, except for internal implementation only changes
Write a comprehensive commit message
Relate your change to an issue in the tracker if such an issue exists (see this page of Bitbucket documentation for more information on this)
Send a pull request from Bitbucket (more on this here)
To run the pylint unit tests within your checkout (without having to install anything), you need to set PYTHONPATH so that pylint, astroid and the logilab-common are available. Assume you have those packages in ~/src. If you have a normal clone of logilab-common, it will not be properly structured to allow import of logilab.common. To remedy this, create the necessary structure:
cd ~/src
mkdir logilab
mv logilab-common logilab/common
touch logilab/__init__.py
Now, set PYTHONPATH to your src directory:
export PYTHONPATH=~/src
You now have access to the astroid, logilab.common and pylint packages without installing them. You can run all the unit tests like so:
cd ~/src/pylint/test
for f in *.py ; do
echo $f
python -S $f
done
The -S flag keeps distutils from interfering with sys.path. YMMV.
Pylint comes with an easy way to write functional tests for new checks:
The message file should use the default text output format (without reports) and lines should be sorted. E.g on Unix system, you may generate it using:
pylint -rn input/func_mycheck.py | sort > pylint messages/func_mycheck.txt
Also, here are a few naming convention which are used: