API in Django for IIT KGP's ApnaInsti App (derived from InstiApp, IIT Bombay), the one platform for all student activities at Indian Institute of Technology, Kharagpur! ApnaInsti's features include upcoming events, placement blog, news and general information on every active club / body in the Institute.
To setup dependenices, make a new virtualenv, activate it and run pip install - r requirements.txt. Then you can run
python manage.py migrateto create a new database.python manage.py createsuperuserwill let you create a new user to use the admin panel for testing.python manage.py runserverto start a local server.flake8to lint withflake8.pylint_runnerto check for code style and other errors statically withpylintin all files.
It is recommended to set up your IDE with both pylint and flake8, since these will cause the CircleCI build to fail. Google's[Python Style Guide](https: // google.github.io / styleguide / pyguide.html) is followed upto a certain extent in all modules.
Tests can be run in two configurations:
# Without Celery
This is the recommended and default configuration, and should suffice for all developmental purposes except if you are working with async tasks or notifications. Simply use python manage.py test - -settings backend.settings_test to run automated tests.
This is the default configuration for CircleCI builds. To test under this configuration, start a local PostgresQL and RabbitMQ server, and an instance of celery in background with celery - A backend worker - -pool = solo - l info. Once celery is processing background tasks, you can run tests as python manage.py test - -settings backend.settings_test - -keepdb, ensuring that the database test_apnainsti is created in postgres beforehand. The following environment variables must be set:
DJANGO_SETTINGS_MODULEtobackend.settings_testNO_CELERYtofalse
Static OpenAPI specification can be found at http: // server / api / docs/
If you are modifying the API, make sure you regenerate docs by running python manage.py swagger
Here is the template mess sheet to be used: https://docs.google.com/spreadsheets/d/1vrYGMLMRpH7ArHD1tC9V3u-AQHSrc14gqqY9O0h_vRk/edit?usp=sharing
Pull requests are welcome, but make sure the following criteria are satisfied
- If you are(possibly) breaking an existing feature, state this explicitly in the PR description
- Commit messages should be in present tense, descriptive and relevant, closely following the[GNOME Commit Message Guidelines](https: // wiki.gnome.org / Git / CommitMessages). Adding a tag to the message is optional(for now). Commits should not have git tags unless they indicate a version change.
- Documentation should be updated when the API is modified
- All required status checks must pass. Barring exceptional cases, relevant tests should be added / updated whenever necessary.
- Barring exceptional cases, Codacy should not report any new issues
- Follow the general style of the project. Badly written or undocumented code might be rejected
- If you are proposing a new model or modifications to an existing one, create an issue first, explaining why it is useful
- Outdated, unsupported or closed - source libraries should not be used
- Be nice!