Information for developers
Here's some information for developers that either want to hack on Task Coach or reuse code.
A Yahoo!Groups mailing list 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 mailing list.
A Sourceforge mailing list is available for receiving commit messages. If you are a Task Coach developer you can join this mailing list.
Task Coach is developed in Python, using wxPython for the graphical user interface and Twisted. 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.
Getting the source
Task Coach source code is hosted in a Mercurial 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
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
Building the distributions
The Makefile is used to build the different distributions of Task Coach. Currently, a Windows installer is built, a Mac OS X 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).
Mac OS X
On Mac OS X, 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 OS X. 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.
Mercurial usage conventions
Releases are tagged ReleaseX_Y_Z 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 may be created to facilitate parallel development, checking in changes while developing, and keep the code on the main trunk releaseable. The process is as follows:
- The feature is discussed on taskcoach-dev.
- If all agree it's a good feature to work on, a Feature_<FeatureName>_Branch branch is created and used for development of the feature.
- When the feature is done, it is announced on taskcoach-dev.
- The feature is tested on all platforms.
- The changes are merged back to main trunk.
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.