1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
.. -*- coding: utf-8 -*-
============
Contribute
============
Bug reports, feedback
---------------------
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:
* https://bitbucket.org/logilab/astroid
* http://www.logilab.org/project/logilab-common
Mailing lists
-------------
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/
Forge
-----
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
.. _mercurial: http://www.selenic.com/mercurial/
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_)
.. _`this page`: https://confluence.atlassian.com/display/BITBUCKET/Resolve+issues+automatically+when+users+push+code
.. _here: https://confluence.atlassian.com/display/BITBUCKET/Work+with+pull+requests
Unit test setup
---------------
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.
Adding new functional tests
----------------------------
Pylint comes with an easy way to write functional tests for new checks:
* put a Python file in the `test/input` directory, whose name starts with
`func_` and should also contains the symbolic name of the tested check
* add the expected message file in the `test/messages` directory, using the
same name but a `.txt` extension instead of `.py`
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:
* Python files starting with 'func_noerror' don't have any message file
associated as they are expected to provide no output at all
* You may provide different input files (and associated output) depending on the
Python interpreter version:
* tests whose name ends with `_py<xy>.py` are used for Python >= x.y
* tests whose name ends with `_py<_xy>.py` are used for Python < x.y
* Similarly you may provide different message files for a single input, message
file whose name ends with '_py<xy>.txt' will be used for Python >= x.y, using
the nearest version possible
|
