3 ms·
Our development setup currently does not need Docker at all. In fact, it does not need a lot more than git and a recent Python version: https://docs.pretix.eu/e
by _rami_ 9y ago
Our development setup currently does not need Docker at all. In fact, it does not need a lot more than git and a recent Python version: https://docs.pretix.eu/en/latest/development/setup.html https://docs.pretix.eu/en/latest/development/setup.html
I agree that this is an opinionated setup and I do see the value of a development setup that mirrors production closely.
(1) During testing, in-RAM SQLite databases are really fast and well capable of running tests in parallel. We have a test suite of ~2000 tests that currently needs ~4min to run on a modern notebook with four threads, so this matters.
(2) pretix is an open source project. If we'd only have a small number of developers in an in-house team, I wouldn't care at all. However, there are many people contributing small and large features and fixes to pretix, and many of them are drive-by contributions: People fixing a problem they just experienced and then leaving again. I want to make it easy for these people, even if they use operating systems where installing Docker first might be a hoop they do not want to jump through.
That said, deprecating MySQL at some point would also force all self-hosting users of pretix to go through all the steps we did here, so this wouldn't be viable in the short term.
- _rami_ 9y agoI may add that our development setup has no external service dependencies, redis is optional as well. Of course, we wouldn't recommend that in production, but we're kinda proud that it's possible.
- fovc 9y ago2000 tests in 4 minutes actually sounds really slow. We use postres and our Django tests run at roughly 9000/min on 3 year old laptops. Start your pg container once and use Django's -k flag when running tests to avoid start up times. We also take care to separate DB access from business logic and to unit test those separately.
- _rami_ 9y agoSure, the main reason for this is that nearly all of our tests touch the database and operate on a comparatively high level, we have way more things in a fuzzy category between functional and integration tests than actual unit tests. This is of course a flaw in our test writing, but it's what we have right now ;)
- bpicolo 9y agoTop down integration tests might be slow, but they're a really top notch way to actually know your code works in dynamic language, mvc-style webapps. Can't blame you there.
- StavrosK 9y agoI second this. I like to have my Django projects using SQLite and a redis mock until I actually need Postgres- and redis-specific functionality, at which point I switch to docker-compose. Before that point, I enjoy the simplicity.