Joachim Jablon
Joachim Jablon
While I'm not sure it's a great idea to let people write things in the DB using Django, there's no harm in exposing our 2 tables as django models, so...
@ignaciocabeza [shared](https://github.com/peopledoc/procrastinate/pull/357#issuecomment-736934184) that the experience of integrating procrastinate in a Django project could be improved. I think we would be wise listening to this feedback, reproduce and solve the problems,...
Currently, our own test code takes care of setting up the db and dropping it, etc. I wonder if https://pypi.org/project/pytest-postgresql/ or https://pytest-pgsql.readthedocs.io/en/latest/ could help. The first one looks simpler, the...
This is a 2-fold ticket: - Without a py.typed, our type annotations cannot be used by projects using procrastinate, and it's quite sad. Let's add a py.typed (see https://www.python.org/dev/peps/pep-0561/ )...
Our current contributing documentation is really oriented toward the process of contributing. It would be interesting to also document the architecture and codebase itself. Following a suggestion from @xcambar, there...
Currently: - We're not making explicit the supported PG versions - We're not testing the supported versions I definitely don't want to make a cartesian product of supported python and...
It would be nice if the CI could fail when a PR contains migration files whose name reference a procrastinate version (a.k.a git tag) that is not the latest. This...
As pointed out by @k4nar, it might be interesting to evaluate how hard AnyIO would be to implement in procrastinate, and it would allow us to provide a better solution...
We need an abstraction layer over json loading and dumping because: - It's needed in connectors (and we wish we wouldn't have to set it up in every connector) -...
Taking things from #183: - We do need tests for the SQL. This is something we don't really have. - We planned to have migration/schema tests with pum, but we...