Introspect AppConfig instead of requiring users to declare ARCHES_APPLICATIONS

[jacobtylerwalls]

In future work, what do you think about removing the ARCHES_APPLICATIONS setting altogether? It's occurred to me before that it's the job of the arches application, not the installer, to know whether the app is arches-related.

If the AppConfig in an arches application had is_arches_application = True, then anywhere in core that reads from that setting could just interrogate it like this (probably as a property or something):

In [1]: from django.apps import apps

In [2]: apps.get_app_config('arches_templating').is_arches_application
Out[2]: True

...and then anybody installing it doesn't have to know or care about installing it as an ARCHES_APPLICATION, it just goes into INSTALLED_APPS like every other django app and call it a day.

_Originally posted by @jacobtylerwalls in https://github.com/archesproject/arches/pull/11002#discussion_r1629797485_

[chrabyrd]

@jacobtylerwalls It looks like this may not be possible, we need this information available when settings.py is read by webpack, and there's doesn't seem to be a decent way to have the app registry load at that point

https://docs.djangoproject.com/en/5.0/ref/applications/#initialization-process

[jacobtylerwalls]

I think we can just call django.setup(). I'm making good progress just using that.

[chrabyrd]

I think we can just call django.setup(). I'm making good progress just using that.

Cool, didn't work for me but I'm interested to see what you come up with! 🤞

[jacobtylerwalls]

Yeah you put your finger on it, the settings.py file itself is the hardest place to do this, but I have a little PoC to look at.

If we extend this with other attributes has_models = True, has_business_data = True, we won't need to send that to webpack, we won't be executing the settings.py file as a module, and we'll probably have an easier time.

[jacobtylerwalls]

Fixed in #11016