docker localdev

[brianporeilly]

Relevant issue: N/A

Description:

Setup local docker development environment.

Also update deps (to fix tests and get docker compose build working)

Notes:

• https://github.com/itsthejoker/django-lightweight-queue seems to cause the error Could not parse version constraint: ~=3.* with poetry > 1.2, which is interesting because it's declared the same way in the upstream repo: https://github.com/thread/django-lightweight-queue/blob/master/pyproject.toml#L22
  • it's not clear to me offhand what the difference is between the fork and the original, so I bypassed this by switching back
  • This may not be preferred, feel free to suggest something else.

Testing Instructions:

docker compose up

Checklist:

• Code Quality
• Pep-8
• Tests (if applicable)
• Success Criteria Met
• Inline Documentation
• Wiki Documentation (if applicable)

[itsthejoker]

The issue with lightweight-queue is that it can't handle the way that we declare the settings in this project; by using alexandria.settings.routing as the starting settings file, DLQ expects that all the settings will be available immediately in that file instead of querying the settings later when they're needed (which is how systems like Django Rest Framework handle it). My fork inserts that functionality while we wait for thread/django-lightweight-queue#62, thread/django-lightweight-queue#64, and thread/django-lightweight-queue#70 to be merged.

[itsthejoker]

I've also been thinking that it would be easier to move to a different task runner; the problem is finding something that is light enough to run the very small list of things we need to do, which is essentially sending emails and fetching images. That's obviously out of scope for this, but if you have any suggestions about options then I'm open to them over here: #24

Mostly it's that I think that dealing with Celery is completely overkill for the complexity level here. Ideally I'd switch to a task queue system that uses Postgres as the backend (because the number of tasks is really just that small) but as email counts grow then keeping redis around (and potentially using it as a cache as well) isn't a bad idea.