Martin Zibricky edited this page Nov 2, 2015 · 6 revisions


Our git repository is at github:

  • branch master
    We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.

  • branch develop
    We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”.
    This is where any automatic nightly builds are built from.

Please read Development Workflow and Development Commit Messages.

More information to come here.

Guidelines for commits

  • Commit often and in logical chunks
    A commit should be one (and just one) logical unit. It should be something that someone might want to patch or revert in its entirety, and never piecewise. If it could be useful in pieces, make separate commits.

  • Write meaningful commit messages.
    Using atomic commits will result in short, clear, and concise commit messages. Non-atomic commits make for awful run-on commit messages.

  • Try to make small patches (i.e. work in consistent increments).

  • Separate changes that affect functionality from those that just affect code layout, indendation, whitespace, filenames etc. This means that when looking at patches later, we don't have to wade through loads of non-functional changes to get to the important parts of the patch.

  • Especially don't mix different types of change, and put a standard prefix for each type of change to identify it in your commit message.

  • Restrict all whitespace changes to a specific type and document as such.

  • Restrict refactorings (that should not change functionality) to their own commit (and document).

  • Restrict functionality changes (bug fix or new feature) to their own changelists (and document).

  • If possible, commit often. This helps to avoid conflicts.

  • Only push when your tree passes validation: see TestingPatches.

  • Discuss anything you think might be controversial before pushing it.

pyenv and PyInstaller

  • clone pyenv repository $ git clone ~/.pyenv
  • clone virtualenv plugin $ git clone ~/.pyenv/plugins/pyenv-virtualenv
  • add to .bashrc or .zshrc:
# Add 'pyenv' to PATH.
export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"

# Enable shims and autocompletion for pyenv.
eval "$(pyenv init -)"
# Load pyenv-virtualenv automatically by adding
# # the following to ~/.zshrc:
eval "$(pyenv virtualenv-init -)"
  • Install python version with shared libpython (necessary for PyInstaller to work)
$ env PYTHON_CONFIGURE_OPTS="--enable-shared" pyenv install 3.5.0
  • virtualenv $ pyenv virtualenv 3.5.0 venvname
  • activate virtualenv $ pyenv activate venvname
  • deactivate virtualenv $ pyenv deactivate

Other Development Documentation

Useful Links


Python Distributions


Operating Systems



Temporary Files
Side-by-side assembly

Mac OS X


Other tools similar to PyInstaller