Am 23.02.23 um 17:09 schrieb Jörg Breitbart:
Ah sorry for the fuzz, I read too much into your idea and jumped to
the conclusion, that you want to extend INSTALLED_APPS at runtime.
no prob ;-)
As you already pointed out, the proper app ordering might be a bigger
issue for an automated app discovery. Not sure how you solved that,
this might need some tree balance logic, but the question remains,
where to get the info "xy must be loaded before/after z" from in the
first place. Ideally apps should be loading position independent, but
thats not always the case, and you might even run into edge cases,
where a proper loading strategy cannot be found due to incompatible
before/after requirements.
I am exploring 2 ways of adding app strings to INSTALLED_APPS. Code says
more than words:
class PluginManager: ... @classmethod def alter_installed_apps(cls,
installed_apps:list[str], group:str) ->list[str]:
"""Lets plugins update INSTALLED_APPS and add their own apps to it, in
arbitrary order. Call this method directly after your
settings.INSTALLED_APPS declaration. """
I'm not sure if altering the passed list is better, or returning a new
one. would be more explicit to see what it does.
The method
1. searches for an *alter_installed_apps* method in the main plugin
module, which takes the INSTALLED_APPS as first argument, and calls it.
So I give the plugin itself the possibility to place itself (and evtl.
needed other modules) at indexes of the INSTALLED_APPS list *they* need
and find appropriate. This should work well for many apps that have
special requirements like "should be placed after
django.contrib.staticfiles", but does not cover real dependency
checking, especially does not cover inter-dependencies of 2 plugins -
the first loaded plugin does not know about the second, as at time of
calling the first one, INSTALLED_APPS does not contain the second one.
2. if this does not exist, it searches for an INSTALLED_APPS list in the
main module as stated earlier, for dumb modules that just need to be
loaded, no matter which order. This list is plainly appended to the main
INSTALLED_APPS.
At time of calling plugin implementations via their hooks, they provide
"weight" attrs and get ordered by this attr when iterating over them. So
each interface hook can have it's own ordering, which works perfectly.
But that doesn't solve the dependency resolution problem of
INSTALLED_APPS. One of my solutions is: Use Python's way: I declare
dependencies in pyproject.toml, so dependency resolution is done by pip.
And in Django, I can already be sure everything is installed as
intended, and just order INSTALLED_APPS like I want to.
But it's not perfect, I know.
So thanks Jörg for your helpful comment. I wasn't quite sure about if I
did something stupid.
And thanks for your all engaging in Django, it's really a great piece of
software.
Yours,
Christian
--
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/dfadb69d-d86e-29c6-a752-6f33cb64c906%40nerdocs.at.
