Hi,
We have a Django project with multiple optional modules toggled by settings flags (e.g., MODULE_ONE, MODULE_TWO, etc.). Historically, some migrations added dependencies conditionally based on these flags. This creates a non‑deterministic migration graph: if a module is disabled when migrating, some dependencies are skipped, and later enabling that module can lead to inconsistent ordering or missing data.
We’re considering a safer approach: always install all apps so migrations can run consistently, and use module flags only for UI/URL routing and feature access. The challenge is how to handle the existing historical migrations that had conditional dependencies without rewriting history in production.
We also have two deployment modes (two settings files): a single‑site setup and a multi‑site setup using django.contrib.sites (with per‑site configuration). In multi‑site mode, each site uses its own database via a custom DatabaseRouter. Are there Django‑specific pitfalls to watch out for when mixing optional modules + migration stability + contrib.sites + multi‑database routing? In particular, anything that commonly breaks or needs special care when switching modules on/off per site?
Additional context (clarification):
Our project has apps that can be enabled or disabled per customer. Some apps are always enabled; others are added to INSTALLED_APPS conditionally based on MODULE_* flags. If we later re‑enable an app, its missing tables are created by running that app’s migrations.
The problem is that some apps depend on other apps, so when a dependency is disabled, the migration dependency becomes conditional too (based on MODULE_). Over time we’ve also run into runtime issues where models are missing in Python views because an app is disabled. This led us to consider a different approach: run all migrations regardless of module flags, and restrict only the UI/URL routing based on MODULE_.