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:
- Enter the django container:
docker exec -ti django_server bash
- 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. Anordinaryuser
can be converted to atemplatedesigner
by asuperuser
. - 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 beFalse
- 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.