EatLint

Breaking News

Okay, not so breaking, but it is important. Like many Trac sites out there, this project has gotten a lot of spam thrown in because there wasn't any filtering turned on. For the near term, I have turned off anonymous writes. To the few people who have been anonymously restoring pages and submitting actual tickets, Thank You. It's nice to see that some people care. :) Now, I'd rather not force people to create accounts and what-not so I'll be looking into other options for spam control. Please stay tuned because I don't want this site locked up forever!

Update 04/01/09: I enabled some spam filtering so hopefully that will help. For now I have re-enabled some permissions for the wiki and tickets.

Current Status

EatLint is currently compatible with Trac 0.10. Trac is currently in the 0.11 range and as of Bitten r622, thanks to hodgestar and dfraser, EatLint's functionality has been rolled into Bitten trunk. What does this really mean? This means that if you are using an SVN checkout of Bitten then you no longer need EatLint and once Bitten reaches its next release you won't even have to worry about it. EatLint will stick around for those who might still be using Trac 0.10 -- for instance when running a distribution of Linux that hasn't updated their packages in a while. Moving forward though, the changes that will/would go into EatLint will be submitted to Bitten directly so eventually that will be your one-stop shop.

About

EatLint is a Trac plugin that adds a lint report summarizer and a lint chart to Bitten. This means that when a Bitten build that includes a lint step the output can not only be captured but reported on. The report shows the number of problems per file by category: convention, refactor, error, and warning as well as showing the totals for each file, for each category, and a grand-total showing the state of the entire project. Similarly the chart plugin charts the total number of problems as well as individual lines for each category. This gives you an idea of the readability of your project's code over time.

License

EatLint's code and templates are based on the code and templates provided by the Bitten project for coverage and unittest data. The Bitten code and templates are provided under a BSD-style license and so is this plugin. Please see License for a copy of the license.

Example

An example build recipe might like this:

<build xmlns:python="http://bitten.cmlenz.net/tools/python"
       xmlns:svn="http://bitten.cmlenz.net/tools/svn"
       xmlns:sh="http://bitten.cmlenz.net/tools/sh">

  <step id="checkout" description="Checkout source">
    <svn:checkout path="${path}" url="http://echospiral.com/svn/eatlint" revision="${revision}"/>
  </step>

  <step id="lint" description="Gather lint report">
    <sh:exec executable="pylint" args="eatlint -f parseable" output="pylint.out"/>
    <python:pylint file="pylint.out"/>
  </step>

</build>

Installation

Installation:

Installation is done just as for any other Trac plugin. Using the easy_install command from setuptools is the easiest (provided you have already setuptools installed):

easy_install eatlint

Or you can access the releases directly on the EatLint Cheeseshop page.

After it is installed you must configure your Trac project to use the plugin. Edit conf/trac.ini in your Trac directory to include this:

[components]
eatlint.* = enabled

Future

I'm currently looking to add some components for analyzing .Net assemblies (think C# and VisualBasic?). These tools report significantly different information so I'll probably end up creating a new report category. Stay tuned for more information.

These additions would be made:

• A bitten.recipe_commands entry point in order to import code analysis statistics into the bitten build db.
• An IReportSummarizer component for summarizing code analysis.
• An IReportChartGenerator component for charting code analysis over time.
• Templates for the above (similar to EatLint's existing pylint templates).
• As a consequence of the above, Bitten's build db will end up with another report category. The name of this category is undecided but considering how many different statistics each code analysis tool reports it may be necessary to pick something pretty package-specific.

At least as a starting point I am looking at supporting Microsoft's FxCop?. This tool is free (as in beer) and seems like a logical starting point.