Package: devilry
devilryDevelopRequires:https://github.com/pyenv/pyenvDocker (Docker desktop or similar)Use conventional commits for GIT commit messagesSeehttps://www.conventionalcommits.org/en/v1.0.0/.
You can use this git commit message format in many different ways, but the easiest is:Use commitizen:https://commitizen-tools.github.io/commitizen/commit/Use an editor extension, likehttps://marketplace.visualstudio.com/items?itemName=vivaxy.vscode-conventional-commitsfor VScode.Just learn to write the format by hand (can be error prone to begin with, but it is fairly easy to learn).Install hatch and commitizenNOTE: You only need hatch if you need to build releases, and you
only need commitizen for releases OR to make it easy to follow
conventional commits for your commit messages
(seeUse conventional commits for GIT commit messagesabove).First install pipx with:$ brew install pipx
$ pipx ensurepathThen install hatch and commitizen:$ pipx install hatch
$ pipx install commitizenSeehttps://github.com/pypa/pipx,https://hatch.pypa.io/latest/install/andhttps://commitizen-tools.github.io/commitizen/for more install alternatives if
needed, but we really recommend using pipx since that is isolated.Install development dependenciesInstall a local python version with pyenv:$ pyenv install 3.10
$ pyenv local 3.10Install dependencies in a virtualenv:$ ./recreate-virtualenv.shAlternatively, create virtualenv manually (this does the same as recreate-virtualenv.sh):$ python -m venv .venvthe ./recreate-virtualenv.sh script is just here to make creating virtualenvs more uniform
across different repos because some repos will require extra setup in the virtualenv
for package authentication etc.Install dependencies in a virtualenv:$ source .venv/bin/activate   # enable virtualenv
$ pip install -e ".[dev,test]"Upgrade your local packagesThis will upgrade all local packages according to the constraints
set in pyproject.toml:$ pip install --upgrade --upgrade-strategy=eager ".[dev,test]"Run postgres and redis$ docker-compose upRun dev server$ source .venv/bin/activate   # enable virtualenv
$ ievv devrunCreate or re-create a devdatabaseYou should always clear the database before recreating it. The easiest way is just to clear the docker resources (and volumes) and start it again.$ docker-compose down -v
$ docker-compose upRun dev server (in a new terminal)$ source .venv/bin/activate   # activate virtualenv
$ ievv devrunLoad devdatabase SQL-file (in a new terminal)$ source .venv/bin/activate   # activate virtualenv
$ docker-compose exec -T postgres psql -U dbdev --dbname=dbdev -p 5432 -h localhost < devilry/project/develop/dumps/default.sql
$ python manage.py migrate
$ ievv customsql -i -rIf the dump should be updated for e.g new migrations, run the following and commit to repo:$ docker-compose exec -T postgres pg_dump --clean --no-owner --no-acl --no-privileges -U dbdev -h localhost -p 5432 dbdev > devilry/project/develop/dumps/default.sqlRun tests$ source .venv/bin/activate   # enable virtualenv
$ pytest devilryBuild css/javascript:$ source .venv/bin/activate   # activate virtualenv
$ nvm use 14    # May need to run "nvm install 14" first
$ ievv buildstatic
... or if you want to watch for changes ...:
$ ievv buildstatic --watchTo remove and reinstall all node-packages:$ source .venv/bin/activate   # activate virtualenv
$ nvm use 14    # May need to run "nvm install 14" first
$ ievv buildstatic --npm-clean-node-modulesDestroy postgres and redis$ docker-compose down -vDocumentationhttps://devilry.readthedocs.ioReleaseTranslationsTo translate new texts, do the following:ievv makemessagesTranslate the .po files. Poedit is a great tool for this.ievv compilemessagesCommit the changesSet version and build staticfilesFirst make sure you have NO UNCOMITTED CHANGES!Release (create changelog, increment version, build staticfiles, commit and tag the change) with:$nvmuse14$tools/release/prepare-release.pyprepare--apply# This will bump the version and then build and commit staticfiles.$gitpush&&gitpush--tagsNOTE (release):cz bumpautomatically updates CHANGELOG.md, updates version file(s), commits the change and tags the release commit.If you are unsure about whatcz bumpwill do, run it with--dry-run. You can use
options to force a specific version instead of the one it automatically selects
from the git log if needed, BUT if this is needed, it is a sign that someone has messed
up with their conventional commits.cz bumponly works if conventional commits (see section about that above) is used.cz bumpcan take a specific version etc, but it automatically select the correct version
if conventional commits has been used correctly. Seehttps://commitizen-tools.github.io/commitizen/.If you need to add more to CHANGELOG.md (migration guide, etc), you can just edit
CHANGELOG.md after the release, and commit the change with adocs: some useful messagecommit.Theczcommand comes fromcommitizen(install documented above).What if the release fails?SeeHow to revert a bumpin thecommitizen FAQ.Migrationguide and changelog (for official readthedocs)Add a migration guide to not_for_deploy/docs/sysadmin/migrationguides/Add a changelog to not_for_deploy/docs/user/changelog/Release to pypi:$hatchbuild-tsdist
$hatchpublish
$rmdist/*# optional cleanup