Task Coach - Your friendly task manager
Here's some information for developers that either want to hack on Task Coach or reuse code.
A Yahoo!Groups mailinglist is available for discussing the development of Task Coach. You can join by sending mail to email@example.com or alternatively, if you have a Yahoo id (or don't mind creating one), join via the webinterface.
You can browse the archive of messages without subscribing to the mailinglist.
A Sourceforge mailinglist is available for receiving commit messages. If you are a Task Coach developer you can join this mailinglist.
Task Coach is developed in Python, using wxPython for the graphical user interface. On Windows, Pywin32 is used as well. For generating the API documentation you need to have Epydoc installed. For generating inheritance diagrams you need to have Graphviz installed.
The few other libraries (other than those provided by Python, wxPython and Pywin32) that are used are put into the taskcoachlib/thirdparty package and included in the source code repository.
You are free to use whatever IDE you want. To make use of the Makefile you need to have make installed. It is installed on Linux and Mac OS X by default. On Windows we recommend you to install Cygwin which provides a shell (bash) and a whole range of useful utilities. Make sure to explicitly include make in the Cygwin setup program because the standard install doesn't contain make.
Task Coach source code is hosted in a Subversion repository at SourceForge. You can check out the code from the repository directly or browse the repository. Please read the file HACKING.txt after checking out the sources. You can generate documentation with Epydoc and Graphviz from the Makefile: make dot epydoc.
Tests can be run from the Makefile. There are targets for unittests, integrationtests, releasetests, and alltests. These targets all invoke the tests/test.py script. Run tests/test.py --help for many more test options (including profiling, timing, measuring test coverage, etc.).
The Makefile is used to build the different distributions of Task Coach. Currently, a Windows installer is built, a Mac OSX dmg file, RPM and Debian packages are created and the sources are packaged as compressed archives (.zip and .tar.gz). The Makefile contains targets for each of the distributions. Most of the code for the actual building of the distributions, using the python distutils package, is located in make.py. In turn, make.py imports setup.py. These two files were split so that setup.py only contains distutils information related to installing, while make.py contains all information related to building the distributions. Only setup.py is included in the source distributions.
On Windows, py2exe is used to bundle the application with the python interpreter and wxPython libraries. Innosetup is used to create an executable installer. All the necessary packaging code is in make.py and driven from the Makefile (windist target).
On Mac OSX, py2app is used to bundle the application. The resulting application is packaged into a dmg file using the hdiutil utility, which is part of Mac OSX. All the necessary packaging code is in make.py and driven from the Makefile (dmg target).
We create RPM and Debian packages on Ubuntu (rpm and deb targets) and a Fedora RPM package on Fedora (fedora target). Alternatively, Linux users that have installed python and wxPython themselves (if not installed by default) can also use the source distribution. The source distributions are created by the sdist Makefile target.
Class names are StudlyCaps. Method names are camelCase, except for wxPython methods that are called or overridden because those are StudlyCaps. At first this looked ugly, a mixture of two styles. But it turned out to be quite handy, since you can easily see whether some method is a wxPython method or not.
Releases are tagged ReleaseX_Y_Z (where X has always been 0 so far) and for each ReleaseX_Y_0 a branch (ReleaseX_Y_Branch) is created to facilitate bug fix releases. The release tagging and branching is part of the release process as documented in release.py.
For new big features, feature-specific branches are created to facilitate parallel development, checking in changes while developing, and keep the code on the main trunk releaseable. The process is as follows:
For small new features, development is done on the trunk, but all unittests should succeed before committing.
Frank keeps a not very frequent blog about lessons learned from developing Task Coach.