Awesome Open Source
Awesome Open Source


Coverage Status Build Status Django 2.2 support Python >=3.6 required


Iguana is a mixture of a ticket system, an issue tracker and an issue management system, heavily based on basic functions being easy to use. So Iguana can help you to plan the next schedule and have always a nice overview about your current tasks depending on your needs, especially for working in groups. There is a kanban board to keep an eye on the progress until the end of the next planning stage and also a backlog to have the ability for scheduling of long-terms. In combination with a mechanism to log time spent on different tasks individually those are the essential functionalities.

For more detailed documentation including a list of features see our github documentation page at


  • Sprintboard
    Provides possibility for short-term scheduling.
  • Backlog
    Provides possibility for long-term scheduling.
  • Olea-bar
    A command line tool to create and edit existing issues.
  • Time-logging
    For both issues and projects, where the value for the later one is simply the sum of relative issue-time-logs.
  • Activity charts
    To keep an eye on the progress of a specific project in both aspects, for time management and amount of activities (e.g. commits). There is an acitivty overview for a project and a different chart for the proportion of issues on a single project.
  • Notifications
    Present multiple ways to notify you for different events. In the future it will be customizable which notifications shall be shown with which feature.
  • Search function
    Search any type of a specific data with regex support.
  • Integrations
    To simplify your workflow
    • Git
    • Slack
    To extend your possibilities on how to use iguana.
  • Markdown support
    For nicer formatting of comments and descriptions.
  • Ansible
    Easy and fast start due to the usage of ansible
  • Docker
    Alternatively an even easier and faster start with Docker




If you want to manually install Iguana, there are some dependencies and actions that must be installed and done before:


TODO: more dependencies required

We generally try to avoid any non-python dependencies but this doesn't always work well. The test cases need the Exempi library so for the development environment this is required and can be installed like this:

apt-get install libexempi3  # Ubuntu/Debian
pacman -S exempi		    # Arch Linux
brew install exempi         # OS X
Setup Python Version

Iguana is currently tested against Python 3.6. It may be also run on higher versions. But if you run into any problems, please test first if they also occour with Python 3.6.

To install Python 3.6 locally (independent from your current system version), you can use pyenv. For installation and setting up pyenv please stick to their documentation:

Once you've got pyenv running execute the following command in the main iguana directory:

pyenv install -v $(cat .python-version)

If everything is correctly setup and if you simply run python in your command shell, the python interpreter with the version specified in the .python-version file should be started.

Common problems using pyenv: Since pyenv is compiling every python version other than your system one direct on your PC, it can happen that after some time this version won't work any more. Often there are errors of missing shared libraries or something like that, when you try to start Iguana or the Python interpreter installed by pyenv. This can happen e.g. after a system update/upgrade. To solve this issue simply reinstall the Python version with the abovev pyenv command.


To setup Iguana in a production environment you simply have to call:

make production

This command runs the following Makefile targets:

  • setup-virtualenv
  • django makemigrations
  • django migrate
  • css


To setup Iguana in a staging environment you simply have to call:

make staging

This does the same as the production target but it creates the staging virtual environment.


To setup Iguana in a development you simply have to call:

make development ++webdriver [<webdriver>]

The <webdriver> option the driver for the setup-webriver target can be specified ("chrome" is used as default). Beside that the following targets are executed:

  • production
  • setup-webdriver <webdriver>

Starting Iguana

Currently Iguana supports only Nginx as web server backend. For configuring Nginx and using Gunicorn together with Django please stick to the official documentation:

Starting the local Iguana instance

To start the local Django web server simply run:

make run


Build images

Three images can be built with the Dockerfile:

  • development (default)

    docker build -f Dockerfile .

  • staging/production

    docker build -f Dockerfile . --build-arg VARIANT=[staging|production] [--build-arg USE_NGINX=[false|true]]

    The USE_NGINX variable indicates if a (basic) Nginx server should be included in the image. The default value is false!

Start a container

Each Iguana docker image can be started with the following command:

docker exec -d \
	-p 80:8000 \
	-v <data_directory>:/files \
	-e TZ=<time zone> \
	-e PUID=<user ID> \
	-e PGID=<group ID> \
	<Iguana image ID>
Environment variable Default value Description
TZ UTC Set the time zone for the container, e.g. Europe/Berlin
PUID 1000 The ID of the user running Iguana in the container
PGID 1000 The group ID of the above user

But in staging/production environment more configuration should be done by the user! Therefore a settings.json file is placed in the Docker volume after the first run. You can edit this file to your needs (see Configuration section -> settings.json). To apply the canges simply restart the container. Please look especially at the SECRET_KEY and HOST/ALLOWED_HOSTS settings!

If a Nginx server was included in the image (with USE_NGINX=true), the nginx.conf file can also be found on the Docker volume. But for real production environments, a separate Nginx container is recommended!

All files uploaded to Iguana are placed in the media directory on the Docker volume.

TODO: add DockerHub badges and links

Using Ansible for deployment

TODO: write Ansible instructions


  • TODO: write instructions for git integration
  • TODO: write instructions for slack integration

Makefile targets

These targets can be run with:

make <target> [++option]

Note that options have to begin with + or ++ instead of - or --. This is due to a bug that prevents passing options to make targets.


  • help
    Prints a short description for each Makefile target.

  • production
    See subsection Production.

  • staging
    See subsection Staging.

  • development [+w <webdriver>]
    See subsection Development.

Django management:

  • django <command> [<args>]
    Any command and its arguments gets directly passed to Django's script. Please have a look at the official Django documentation for a list of supported commands:

  • test [+a <appname>|+f|+c] [+i]
    Run the Django unit tests. If an application name is provided with +a, only that app is tested. To run the functional tests use the +f option. If all tests should be run, use option +c. With the option +i the warnings and errors from imported packages get suppressed.

  • run
    Run the default django server.

Source code management:

  • setup-virtualenv
    This target prepares the virtual python environment in which this project is executed. The packages for the virtual environment are defined in the file production.req or development.req. This depends on which main target you have chosen before.

  • css
    See section Styling.

  • set-webdriver <webdriver>
    This target configures the webdriver for the functional tests. You can replace <webdriver> with chrome, firefox or safari.

  • requirements

    • install
      Reinstall all packages in the virtual environment. Which packages are installed depend on what main target you have run in the initialization process.
    • check
      Check whether the used requirements are up to date or not.
  • coverage [+a <appname>|+f|+c] {report,html,xml,erase}
    Run the coverage tool on the Django tests. With argument +a anapp for which the coverage should be measured can be specified. +f measures the coverage for all funtional tests and +c performs a measurement across all tests. To get a better output you can run one of the following commands:

    • report
      Get the coverage in text form.
    • html
      Get the coverage as a html website.
    • xml
      Get the coverage as a xml file.
    • erase
      Delete the last coverage report.
  • list

    • bugs
      List all occurrence of the tag TODO BUG.
    • missing_testcases
      List all occurrence of the tag TODO TESTCASE.
  • add-license
    Insert the license header into all source files.

  • new-release
    Tag the current commit as a production release.


Currently the style is stored in src/common/scss/iguana.scss. To build it run make css. For Selenium tests use StaticLiveServerTestcase instead of LiveServerTestcase to make sure static files (like css) are served.

Documentation on Sass and SCSS: sass-lang guide

I propose we use SCSS, as it is a superset of CSS and the default Sass syntax. If we change our mind, there are tools to convert between the two syntaxes.


Please use translation hooks in templates (see _base.html for an example) and code (ugettext as _).

You can create/update the *.po in the locale directory by running make django makemessages +l <lang-code>. The default language is English (code: en). This file is where the actual translations go. It should be checked in after updating. This uses the GNU gettext toolset.

For new translations to be usable by django, run make django compilemessages.

To see a page in a different language, open it with a different language prefix in the url. For example /de/login instead of /en/login.


Iguana has a lot of settings that can be changed by the user. The settins files are stored in the src/common/settings package. The package structure is:


A default init-file gets created by the Makefile target initialize-settings (see section Makefile targets).
For the development process this file can contain additional settings that should not be published in the repository. Mainly the Django-SECRET_KEY = '...' setting is defined here, when the project is in the development environment.
Important: The file must start with the line:

from <site_config> import *

You can replace <site_config> with (don't forget the '.'):

  • .local_conf: the development settings are loaded
  • .global_conf: the production and staging settings are loaded

This file contains the basic settings that are the same for the other two configuration files.
This file should not be changed by the user! It contains basic settings for the Django framework. Changing these settings without knowing what you do could lead to unexpected behaviour.

Basically this file contains all settings that are required to run Iguana in an staging or production environment.
But the settings that should be changed by the user are loaded from the file settings.json. See section settings.json.

This file contains all settings that are required to run Iguana in a development environment.
Normally there's no need to change these settings.


TODO: describe settings.json

Plan of the future

For short and long term plans see the official documentation.

Question and answers

For questions and answers please also stick to the official documentation. In case you have any other questions don't hesitate to hit us up.


Iguana was mainly developed with the Django framework (

Main license

Iguana is licensed under the CC-BY-SA license: Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Since we use the version 4 of CC-BY-SA there is not necessarily an incompatibility with GPL - see Can I apply a Creative Commons license to software? and ShareAlike compatibility: GPLv3. If you see any problems that are caused by that CC-BY-SA license tell us and we might find a solution.

Plug-in licenses

Besides the following plug-ins were used:

Plug-in / Software License
bleach Apache License 2.0
celery BSD License
chromedriver Apache License 2.0
coverage Apache License 2.0
Django BSD License
django-activity-stream BSD License
django-autocomplete-light MIT License
django-bootstrap3 Apache License 2.0
django-cuser BSD License
django-bootstrap-datepicker-plus Apache License 2.0
django-extensions MIT License
django-filter BSD License
django-pagedown BSD License
django-redis BSD License
djangorestframework BSD License
djangorestframework-simplejwt MIT License
django-sendfile BSD License
django-simple-captcha MIT License
django-test-without-migrations MIT License
GitPython BSD License
gunicorn MIT License
markdown BSD License
markdown-urlize BSD License
model-mommy Apache License 2.0
Pillow PIL Software License
piprot MIT License
Piexif MIT License
ply BSD License
psycopg2 GNU LGPL v3.0
pycodestyle Expat License
python-dateutil BSD License
python-magic MIT license
python-xmp-toolkit ESA/ESO and CRS4 license
pytz MIT license
redis BSD License
requests Apache License 2.0
selenium Apache License 2.0
sendgrid-django MIT License
slackclient MIT License

Get A Weekly Email With Trending Projects For These Topics
No Spam. Unsubscribe easily at any time.
Python (1,141,503
Docker (33,967
Django (12,720
Rest Api (8,177
Ansible (6,821
Markdown (6,636
Project Management (671
Issue Tracker (220
Kanban Board (154
Related Projects