Making git and pylint interact
Hi! This is a question about making your favorite VCS and pylint interact. The idea is that sometimes there's a project and you're running pylint on it, but you want to distinguish among two kinds of errors: 1) Errors introduced by the last few commits. 2) Errors that have been around forever and that are not the committers responsibility to fix. If you have a lot of errors of type (2) you don't want the committer to have to wade through them looking for any errors they might have introduced. (Of course, there is a very hard working person in the background who is constantly working on addressing the many errors of type (2)). So, it is easy to automate running pylint on a tree that includes the last few commits (as specified by the user) and also on a tree that is missing the last few commits. The problem is diffing the results from running pylint on these two different trees. I see that the pylint results are dumped in pickle format into a pylint.d directory. Presumably it is from that info that the textual reports are extracted and displayed, though I am not certain. I can see that something similar has been proposed before: http://www.logilab.org/ticket/20386. However, the difference is that I assume two pylint.d directories, one for each source tree, and I'm interested in comparing them, somehow. It is not sufficient to do an exact compare, as line numbers and so forth may be changed. I'ld welcome suggestions or if anybody has knowledge of any existing utility that does this that would be great. Thanks! - mulhern
Hi!
This is a question about making your favorite VCS and pylint interact.
The idea is that sometimes there's a project and you're running pylint on it, but you want to distinguish among two kinds of errors: 1) Errors introduced by the last few commits. 2) Errors that have been around forever and that are not the committers responsibility to fix.
If you have a lot of errors of type (2) you don't want the committer to have to wade through them looking for any errors they might have introduced.
(Of course, there is a very hard working person in the background who is constantly working on addressing the many errors of type (2)).
So, it is easy to automate running pylint on a tree that includes the last few commits (as specified by the user) and also on a tree that is missing the last few commits.
The problem is diffing the results from running pylint on these two different trees.
I see that the pylint results are dumped in pickle format into a pylint.d directory. Presumably it is from that info that the textual reports are extracted and displayed, though I am not certain.
I can see that something similar has been proposed before: http://www.logilab.org/ticket/20386.
However, the difference is that I assume two pylint.d directories, one for each source tree, and I'm interested in comparing them, somehow.
It is not sufficient to do an exact compare, as line numbers and so forth may be changed.
I'ld welcome suggestions or if anybody has knowledge of any existing utility that does this that would be great. At edX, we wrote a tool called diff-cover that produces differential coverage reports, and also pylint and pep8 reports. It lets the developer focus on the effect of the changes they are making, rather
On 3/18/14 6:27 PM, Anne Mulhern wrote: than on the entire working tree: https://github.com/edx/diff-cover --Ned.
Thanks!
- mulhern
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
Hi! Thanks for your responses. One thing I noticed is that the responses I got all took the same approach: report only errors that are located on lines that have changed. I'll call this the code diff approach. What I was actually looking for was new errors introduced by the changes, which I'll call the pylint diff approach. For instance, if a use of a variable gets deleted by a change, a previous assignment may become unused, and pylint would report the error at the assignment line. This newly introduced error would be left out by the code diff approach. On the other hand, there's an argument that says that even if an error is not created by a change, if it is on a line that you changed, you should probably fix it. So, I think the pylint diff and the code diff approach could complement each other nicely. So again, thanks to everybody who responded, but I'm not entirely satisfied yet, and if anybody has anything further to add, I'm still interested. - mulhern
On 19 March 2014 14:11, Anne Mulhern <amulhern@redhat.com> wrote: [snip]
So again, thanks to everybody who responded, but I'm not entirely satisfied yet, and if anybody has anything further to add, I'm still interested.
- mulhern
I heard that twisted's buildbot configuration is doing something like this.. but is custom code. For example trunk branch has a lot of pyflakes errors but buildbot only look for newly introduced errors... not sure how. -- Adi Roiban
I'm not entirely satisfied yet, and if anybody has anything further to add, I'm still interested.
My thinking is that if the code differences don't tell you what changes in pylint output are important, then maybe either * pylint results should be stored under version control so you can diff them or * pylint should be run on both the reference checkin and the current state of your code In either case, you'd need to do a bit of a tricky dance when messages. To avoid spurious diffs, you might have to substitute "NNN" for your line numbers, compare, then restore the actual line numbers in the messages you present to the user. Skip
participants (4)
-
Adi Roiban -
Anne Mulhern -
Ned Batchelder -
Skip Montanaro