A django site for kinetic models
Clone the project and set up docker and docker-compose (on desktop systems like Docker Desktop for Mac and Windows, Docker Compose is included as part of the Docker Desktop install). Be sure to launch the Docker.app (or ensure the docker daemon is running) before trying to run docker-compose commands.
For the first time, you need to run the initial migrations, which use RMG-models. To do this, first clone the RMG-models repo via ssh or https (ssh shown below):
git clone git@github.com:comocheng/RMG-models.git
Now create a named volume and copy the files over using docker
:
docker volume create rmg-models
docker run --rm \
--volume=/path/to/RMG-models:/source \
--volume=rmg-models:/target \
busybox cp -av "/source/." "/target/"
Then run:
docker-compose up -d
If you get an error ending ...returned a non-zero code: 137
then probably your Docker needs more RAM. On MacOS or Windows you can configure this using your Docker Dashboard app settings. In our experience 2GB is not enough but 4GB is.
If you use MS Visual Studio Code, you can use the debugger by running docker-compose -f docker-compose.debug.yml up
and starting a debugging session using the project's configuration (.vscode/launch.json
).
To run a lightweight, debuggable version of the app, run:
docker-compose -f docker-compose.debug.yml up -d
If you want to setup your development environment on your local machine without the docker container, install pgAdmin4.
Then clone the RMG-models repository and set the RMGMODELSPATH
environment variable to the path where you cloned it:
export RMGMODELSPATH=/path/to/RMG-models/
Also set DBHOST
:
export DBHOST=0.0.0.0
Put these lines in your shell config file (ie. .bashrc
) so you don't have to type it every time.
Now run:
docker-compose -f docker-compose.debug.yml start db
Then open pgAdmin and setup a connection with the following information:
- host: localhost
- port: 5432
- user: postgres
- password: postgres
Keep in mind this environment is not production ready. If you want to work in a production setting, use the application container defined in docker-compose.yml
with a .env
file in the project root.
- The main project is
kms/
- The main app is
database/
When you build the docker container, it automatically applies all current migrations. If you make changes to your code and need to migrate again, either rebuild the image (slow!) or attach a shell to your running container and run the migrate command:
docker-compose exec web sh
Now in your interactive container shell:
python manage.py migrate
Similarly, if you want to nuke your migrations, you can run this in your interactive shell:
python manage.py reset_db
This is useful if RMG-models gets updated and you want to reset your database and migrate again.
Token authentication is required in order to make non readonly requests to the API (POST, PUT, DELETE, etc.). To easily generate a token for development, use the following:
python manage.py drf_create_token <username>
Use the -r
option to regenerate a token for the given user.
We use flake8 for code style checks.
It is configured in the setup.cfg
file.
To check if your changes pass the checks, run:
python -m flake8
We use black to format our codebase.
To format the codebase, cd
to the project root and run:
black .
If you add a .py
file that you don't want formatted, add it to the tool.black
section of the pyproject.toml
.
If you don't want to it to be checked for code style either (likely!), then also add the file pattern to the extend-exclude
option in the flake8
section of the setup.cfg
file.
Whenever you make a change to the models, make sure to add a database migration file to reflect those changes in the database. You can do this easily using the command:
python manage.py makemigrations
If you have a local database and want to update it with new migrations, run this:
python manage.py migrate
In order to update the models and migrate existing data to reflect the new schema, you will have to manually write a data migration.
This project uses the built-in unittest
module with the Django testing framework.
To run tests, run the shell scripts test.sh
and test-migrations.sh
in the docker container.
There are a few different test classes to use when writing tests. When writing simple unit test cases with no backend dependencies (ie. models), use django.test.SimpleTestCase
. When writing unit tests with backend dependencies, use django.test.TestCase
. When writing tests for a specific migration or series of migrations, use django_test_migrations.contrib.unittest_case.MigratorTestCase
.
IMPORTANT: All test files should be in the
/tests/
directory and should be prefixed withtest_
and subsequently snake-cased. Additionally, all unit tests should be suffixed withunit
and all migration tests should be suffixed withmig
. If you do not do this, the test shell scripts will not run properly and your tests with fail in CI!
- Create a feature branch from
master
- When finished, rebase the feature branch to the tip of
master
- Open a PR and perform a Merge once approved