Support for OhCount summaries and charts

[Olaf Meeuwissen <olaf@…>]

I wanted to see line code counts for all of a project's source. In addition, I wanted to see per language counts. Ohloh's ohcount can do that but there was no Bitten ohcount recipe command yet so I put one together. The result is in ohcount.diff​.

Be warned that this is my first real attempt at Python programming, my first time using SQL, I have no idea how this charting stuff works and that I know no Ruby whatsoever. Feel free to rip up the patch.

To use this, you need to add to your recipe (preferably immediately after the checkout) something like:

<src:ohcount paths="bitten" verbose="True" />

This puts the summary produced by running ohcount on all the files in the bitten directory in the Log. Using the default verbose="False", will suppress the summary in the Log. The default value for paths will start at the top-level of the checkout. A Line Count tab on each build page will present a tabular summary of the code counts.

There are two charts. One shows a grand total and the total number of source, comment and whitespace lines over time. The other shows per language grand totals.

Enjoy!

[Olaf Meeuwissen <olaf@…>]

Patch for ohcount support

[Olaf Meeuwissen <olaf@…>]

Replying to Olaf Meeuwissen <olaf@…>:

Be warned that this is my first real attempt at Python programming, my first time using SQL, I have no idea how this charting stuff works and that I know no Ruby whatsoever. Feel free to rip up the patch.

Doh! I completely forgot to mention that I also don't know any Genshi and only very little of the Trac and Bitten internals.

BTW, there is now also a documentation patch​.

[Olaf Meeuwissen <olaf@…>]

Document the src:ohcount command

[osimons]

Thanks for the patch, and this great effort should really not have gone uncommented by us for so long... Hope this has not discouraged you :-) Lines-of-code has come up a number of times, and it would be natural for Bitten to support this.

However, browsing your patches I see that you have made the code available as GPLv3+. Bitten is BSD licensed, and cannot include GPL code. Would you consider changing the license? If not, we cannot incorporate it in any form unfortunately.

[olaf@…]

Thanks for the kudos.

As for the licensing, there is no problem on the GPLv3+ side. The (modified) BSD license used for Bitten is compatible with the GPL.

See

• ​http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
• ​http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
• ​http://www.gnu.org/licenses/license-list.html and search for "Modified BSD"

for details on this.

The license for XML/SWF charts is more troublesome (see source:trunk/COPYING@455​), but I gather that there has been some ​activity during a Bitten Sprint to get rid of that. Good! I'll check if my patches still work.

Assuming XML/SWF charts gets dropped, what are the problems with incorporating GPLv3+ licensed code in Bitten, apart from slightly complicating the licensing conditions? Note that these complications are certainly no more severe than what you have now with the XML/SWF charts copy.

[osimons]

Replying to olaf@…:

As for the licensing, there is no problem on the GPLv3+ side. The (modified) BSD license used for Bitten is compatible with the GPL.

When viewed in isolation it may appear that way, but I beg to differ with your conclusions: It is not a library being linked or called, it is source code offered as a patch for including as part of Bitten. Give the software a few iterations of changes and refactorings from you, me and others and it becomes impossible to separate your GPL code from our BSD code. Which in effect forces us to change the license to GPL - or rewrite any part of Bitten that may include your code.

For the distribution of Bitten the licenses are compatible in the way that the spirit of openness is maintained. However, it places severe limitations on the receivers and users of the source code. Bitten is BSD licensed as we believe our users are better served by letting them use, reuse, distribute in any way they want - open or closed. Your GPL code will end that.

The license for XML/SWF charts is more troublesome (see source:trunk/COPYING@455​), but I gather that there has been some ​activity during a Bitten Sprint to get rid of that. Good! I'll check if my patches still work. Assuming XML/SWF charts gets dropped, what are the problems with incorporating GPLv3+ licensed code in Bitten, apart from slightly complicating the licensing conditions? Note that these complications are certainly no more severe than what you have now with the XML/SWF charts copy.

It is gone, and I've also updated the information in [880]. Licensing was a big reason for this change. Your GPL licensed patch is way, way more troublesome for us than bundling some external compiled flash library.

If you insist on GPL for your code, I suggest you just bundle your efforts as Bitten master & slave plugins. Wrap it with its own setup.py and mark it as a tool and as a entry_point for components. That leaves it a separate install, but should be a fair and workable solution for all.

[olaf@…]

I see your concerns, but at the same time I am not willing to let anyone "proprietarise" my efforts.

I'll have a look at turning my changes into proper Bitten plugins then. Any plugins out there I can take a look at? Where to go for hosting? Trac Hacks?

FWIW, the patch still produces the summary all right, but the charts are completely broken. Of course, I'll have a look at fixing that as well.

[osimons]

Replying to olaf@…:

I see your concerns, but at the same time I am not willing to let anyone "proprietarise" my efforts.

That is your right as author. I have no problem understanding your position. It is just not compatible with the history of Bitten.

I'll have a look at turning my changes into proper Bitten plugins then. Any plugins out there I can take a look at? Where to go for hosting? Trac Hacks?

trac-hacks.org is one option, but you can also do a Bitbucket or Github project. If we don't have it already, Bitten should have a plugins overview page where such plugins should be listed (haven't looked yet).

If you look at the setup.py for Bitten itself, you'll see how both the master and slave are pluggable:

• The master implements standard Trac 'trac.plugins' entry points as used by any plugin built on Trac component code. As seen for instance in my fullblog-plugin setup code, you want to make the module an optional extra that depends on Bitten >= 0.6b1. That way Trac won't try to enable it unless Bitten is also installed (like I do for spamfilter and tags optional modules in my blog plugin).
• The slave build tools additions are 'bitten.recipe_commands' entry points, linking a tool URI to the module and function to call: 'http://bitten.edgewall.org/tools/c#make = bitten.build.ctools:make'.

Drop by the #bitten IRC channel on Freenode when in "development mode", and there should be someone around able to answer questions about this.

As there is nothing further that the Bitten project can do with this ticket, I'm closing it. Good luck with the plugin development, and do ping me/us about getting it properly described and linked in a wiki page here when you get it ready for public use.