William E. Hart's Blog

At PyCon 2009, Aaron Maxwell gave a presentation about the use of BuildBot to support an automated software QA infrastructure. Listening to his talk ( online ) made me think more carefully about the reasons I am not using BuildBot, which I took a look at several years ago.  After working with a custom automated build tool for a few years, I have recently begun using Hudson to automate software quality processes for a variety of open source software packages.  Hudson automates the following QA activities for these packages: portability tests - building packages with different compilers, language versions and compute platforms continuous integration - rapid builds and software tests to provide developers continuous feedback integration tests - builds that test the integration of different software tools archiving QA statistics - test histories, code coverage statistics, build times, etc. managing third-party builds - building third-party libraries that my codes depend on Althou...

The gcovr command provides a utility for running the gcov command and summarizing code coverage results. This command is inspired by the Python coverage.py package, which provides a similar utility in Python. Further, gcovr can be viewed as a command-line alternative of the lcov utility, which runs gcov and generates an HTML output. The gcovr command currently generates two different types of output: Text Summary For each file that generates gcov statistics, gcovr will summarize the number of lines covered, the percentage of coverage and enumerate the lines that are not covered. Cobertura XML An XML summary of the coverage statistics can be generated in a format that is consistent with Cobertura. I find the text summary quite convenient for interactive assessment of coverage, especially as I design tests to improve coverage. The Cobertura summary can be used by continues build tools like Hudson . For example, see the acro-utilib coverage report that was generated with gcovr, ...

I just discovered that the talks at PyCon 2009 were video taped! Excellent! I had fun browsing them last night, looking for clues to the challenges that I face managing several complex Python packages. I am not sure how the PyCon organizers justified the cost for doing this, but I think that this was an excellent idea. I would love to see other conferences adopt this idea (or at least support online publishing of electronic slides). I suspect that this would discourage some people from attending a conference. However, people like me are already traveling too much. Thus, the PyCon organizers did not lose anything with me; I was already unable to attend. Further, having access to the presentations makes me more likely to adopt the techniques/approaches that they are presenting! This sounds like a win-win to me!!

After blogging about Python plugin frameworks earlier this year, I wound up implemented a new framework in the PyUtilib software package.  The PyUtilib wiki provides a detailed description of the PyUtilib Plugin Framework , but here's a brief summary: This framework is derived from the Trac plugin framework (a.k.a. component architecture) Provides support for both singleton and non-singleton plugin instances Includes utilities for managing plugins within namespaces The core framework is defined in a single Python module, which can be used independently from PyUtilib PyUtilib also includes commonly use plugins, such as A config-file reader/writer based on ConfigParser Loading utilities for eggs and modules A file manager for temporary files Although I initially resisted the urge to develop my own framework, I was led to develop this because (1) I wanted a light-weight framework like that provided by Trac, but (2) Trac's framework is not particularlly modular within the Trac so...