This post is about Python distutils. You may wonder, “why distutils?” and not some other Python packaging framework such as setuptools. The reason is that distutils is distributed with Python and it is good enough for simple Python modules. Python offers a few options for packaging, and this can be confusing. That is the other factor in choosing the defacto library that is installed with Python 2 and Python 3.
When first starting with distutils, I landed on the Distributing Python Modules page on docs.python.org, which includes this introduction. This is a great resource, but a little daunting for a newcomer. I left still wondering how to use distutils.
I also found this tutorial for distutils, which included a good outline of the folder structure, but was still a little confusing.
I then found these instructions for packaging Python libraries, which was more complete and had good practical advice.
This post contains links and information about using Mercurial (a.k.a. hg).
The main reason for this post is how to use Mercurial in a software team environment.
I think one of the most important practices is to use semantic versioning when releasing software.
I also like using the successful Git branching model described on nvie.com.
The Hg Init tutorial by Joel Spolsky is good for beginning Mercurial users.
The Mercurial Workflows: Stable & Default by Steve Losh provides a good explanation of why to use a stable and development branch. He also expands on this idea in this Stack Overflow answer about managing release branches in Mercurial. He also has a longer guide to branching in Mercurial.
I personally favor using the default branch as the “stable” or “release” branch. Mainly because in the simplest case, when a project starts with one branch, then it is the default branch. As the project matures, a “develop” branch can be created.
The hgbook discusses how to manage releases and branchy development.
Something that is interesting, and different, from the git branching model is that (apparently) it is difficult to remove branches from an hg repository. Thus, the hgbook discusses using a separate repository for feature branches.