This project has been designed to be installable via setup.py.

Layout:

manage.py
requirements/
|-- django.txt
|-- base.txt
\-- ..
requirements.txt
tests/
src/
\-- easydmp/
   |-- site/
   |   |-- __init__.py
   |   |-- settings/
   |   |   |-- base.py
   |   |   |-- dev.py
   |   |   \-- production.py-example
   |   |-- urls.py
   |   \-- wsgi.py
   |
   \-- [apps] ..

• python >= 3.5
• pip
• graphviz (if you want to be able to graph the flow of templates)
• virtualenv/wrapper (optional)
• some sql database supported by Django

As for the database, it can run on sqlite. It's better to run it on PostgreSQL. It does not depend on any postgres features newer than version 9.3.

Create a virtual python environment for the project. If you're not using virtualenv or virtualenvwrapper you may skip this step.

$ mkvirtualenv -p /usr/bin/python3 --no-site-packages easydmp-env

Activate with:

$ workon easydmp-env

Create a virtual env in the current directory called easydmp-env:

$ virtualenv -p /usr/bin/python3 easydmp-env

Activate with:

$ source easydmp-env/bin/activate

We do not recommend having the actual code inside the virtual env.

Obtain the url to your the repository:

$ git clone <URL_TO_GIT_RESPOSITORY> easydmp

$ cd easydmp
$ pip install -r requirements.txt

$ python manage.py migrate

If you need to change any settings from the default, put a file devsettings.py with the changes somewhere on the python path, and set the environment-variable DJANGO_SETTINGS_MODULE to the dotted path of the devsettings-file.

The docker-compose file runs its own database. After the first docker-compose build and docker-compose up, fill the database with the default development fixture like so:

1. Enter the django container: docker exec -ti django_server bash
2. Load the fixture: python manage.py loaddata devfixtures.json

$ python manage.py runserver

This will use the settings file easydmp.site.settings.dev unless DJANGO_SETTINGS_MODULE has been set.

Load fixtures with python manage.py loaddata devfixtures.json.

Open browser to http://127.0.0.1:8000

The development fixtures set up all lookup tables, and some templates and development users, to speed first time setup for development.

Whenever you make a change that necessitates a migration of the sql, run the migration and create your own devfixtures with:

python manage.py dumpdata auth.Group easydmp_auth dmpt eestore \
--format json --indent 1 --natural-foreign --natural-primary > somesensiblename.json

Never commit to devfixtures.json. It is regenerated by us as part of the release process, whenever a change to the backend SQL tables are accepted, and whenever we find new, useful data to include that will make it easier for new developers to get started.

Three users are created. The password to all of them is niezynarecxaqd. Obviously, these users should not be used in production.

ordinaryuser

This is the default user, and is what is created automatically on login via OAuth. May create and edit plans, invite other user to view and edit plans, share and unshare plans.

templatedesigner

This is an ordinaryuser with additional access to a special version of the admin that allows creating linear templates. An ordinaryuser can be converted to a templatedesigner by a superuser.

superuser

Has access to everything, and may use the admin.

Additional superusers can be created from the command line:

python manage.py createsuperuser

A single group is created, Template Designer. Putting a user in this group will make that user into a templatedesigner.

At least two templates are created: One with multiple linear sections, and one with only a single linear section.

Use a settings-file tailored for the production environment. If there are more than one webserver working together as a cluster, they should all have the same production settings. Assure that the following holds:

• DEBUG must be False
• Generate a new SECRET_KEY (a string of 50 random printable ASCII characters is the norm)
• We recommend setting the environment variable MEDIA_ROOT to a path that is servable by the web server and has a handful megabytes of free diskspace.

We recommend making a deployment-specific project that fetches the code (for instance with curl/wget, pip install or git clone) and adds all the necessary deployment-specific code, including any overrides for settings, templates, static files etc.

.
|-- deploymentmethod
|   |-- settings.py
|   |-- wsgi.py
|   |-- templates/
|   |-- static/
|   |-- requirements.txt
|   .. deployment method specific files
|
.. deployment method specific files

Get the code to where it needs to be, with a script utilizing rsync, git clone, fabric or whatever. We recommend keeping the dependencies in a virtualenv, which means that the web server will need to know about the path to the virtualenv.

If the virtualenv is installed at /path/to/virtualenv and the python version is 3.5, the follwing path must be somehow added to the python path:

/path/to/virtualenv/lib/python3.5/site-pacakges/

If using Apache, do not use mod_python, use mod_wsgi in daemon mode.