At the moment Django() needs to be instantiated before models can be defined (it configures settings and sets up apps). This causes problems for import order of models in other apps.
Ultimately nanodjango is making Django do something it doesn't want to do, so this project will always have limitations. However, this feels like something that I should try harder to address, as it's unexpected and causing problems (see #34)
My idea to solve this is having import nanodjango replace django.db.models.Model with a placeholder that logs subclasses but doesn't initialise them - then swap it out for the proper Model when Django() has run, and initialise the classes then. This is going to be fun, and also a crime against python.
If it works, we're still going to need to get import nanodjango in before any other apps, but that feels a nicer more solveable/manageable problem than putting Django() before the imports.
At the moment
Django()needs to be instantiated before models can be defined (it configures settings and sets up apps). This causes problems for import order of models in other apps.Ultimately nanodjango is making Django do something it doesn't want to do, so this project will always have limitations. However, this feels like something that I should try harder to address, as it's unexpected and causing problems (see #34)
My idea to solve this is having
import nanodjangoreplacedjango.db.models.Modelwith a placeholder that logs subclasses but doesn't initialise them - then swap it out for the properModelwhenDjango()has run, and initialise the classes then. This is going to be fun, and also a crime against python.If it works, we're still going to need to get
import nanodjangoin before any other apps, but that feels a nicer more solveable/manageable problem than puttingDjango()before the imports.