Am 22.02.23 um 22:37 schrieb Jörg Breitbart:
Am 21.02.23 um 22:05 schrieb Christian González:
My original question was HOW would I implement this in a
"good-practice" way, by not violating Django's conventions, and
showing a way it could be done clean.
I think thats not really feasible without big restrictions on the apps
and what they might bring into a running django instance. Main reason
being the multistage bootstrapping with collecting phases, esp. on ORM
side. While it is possible to create models on the fly, they will not
fully integrate properly. You'd have shim in all the bookkeeping,
cache abstractions and static globals (django still has a few of
those) and alter their values in way, that would resemble a clean
startup. And with multithreading things will get really funny here.
Hm - maybe I don't understand this (& Django bootstrap process) in
depth, or I didn't make myself clear enough...
I don't want to interfer with Djangos setup process in various ways.
What you say would be true if GDAPS would try to hook into many
processes Django does at the start.
I just add some strings to INSTALLED_APPS at the time of parsing
settings.py. In fact, there is:
INSTALLED_APPS = [
"django.contrib..."
"..."
"myapp.core"
]
PluginManager.find_apps(INSTALLED_APPS, "myapp.plugins")
Here, PluginManager has a method that receives the INSTALLED_APPS, loads
all plugins' main modules, extracts their INSTALLED_APPS list, and
merges them into the main.
So after this line, INSTALLED_APPS contains additionally e.g.
"myapp.plugins.foo_plugin" and "djmoney".
If you introduce on-the-fly app loading, demand for on-the-fly app
unloading or app updating is around the corner. Thats like opening
pandora's box (from dangling refs to not gc'ing/freeing at all due to
some deeply held ref).
Overall I think any attempt into these on-the-fly directions will lead
to serious stability issues.
I don't want to introduce on-the-fly-anything... This would, as you say
correctly, interfere with Django's internals and eat your dog, or worse.
Never wanted to do that. After that line (code above), everything goes
the normal Django way of loading.
Of course, to add or remove a plugin, you have to restart the server,
and run migrate etc mgmt commands, as I said earlier.
And it **works** perfectly this way, I use it (even unofficially in
production) on a daily base. I just want to know if there is a better
approach than placing an INSTALLED_APPS list (or a method) into the
**main module** of a plugin...
Cheers,
Christian
Cheers,
Jörg
--
Dr. Christian González
https://nerdocs.at
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/23d61d8c-9d4d-23fc-ff30-5e04a885755a%40nerdocs.at.
