Unexpected SystemSettings interaction causing failure to run via wsgi.py

[jacobtylerwalls]

@ekansa reported on the forum a failure to run an arches project via wsgi.py, i.e. not run with runserver. The TL;DR is that we have the default value of APP_NAME being stored in a system settings tile and overriding the project settings file, only under wsgi.py.

Traced it to this unexpectedly evaluating True:

arches/arches/urls.py

Line 789 in f3390ef

if settings.APP_NAME == "Arches":

... because wsgi.py loads system settings from the database:

arches/arches/wsgi.py

Line 39 in f3390ef

settings.update_from_db()

... and we save the value "Arches" for APP_NAME in the database during setup_db, which is going to be incorrect for all cases (only applies to running "naked" core arches like a project):

arches/arches/db/system_settings/Arches_System_Settings.json

Lines 153 to 156 in f3390ef

	"en":{
	"direction":"ltr",
	"value":"Arches"
	}

arches/arches/management/commands/setup_db.py

Lines 234 to 236 in f3390ef

	management.call_command(
	"packages", operation="import_graphs", source=settings_graph
	)

---

@chrabyrd and I didn't notice this when developing f569e09 and related features because we were running the devserver, but arguably this is an orthogonal bug.

We have other cases where we need the value of APP_NAME to be correct:

arches/arches/settings_utils.py

Lines 161 to 162 in f3390ef

	if settings.APP_NAME == "Arches":
	base_path = root_dir_path

---

I reproduced on 7.6.3 with Eric's instructions:

• clone opencontext/arches-via-docker
• checkout the 'local' branch
• cp edit_dot_env .env
• make DEBUG=False (in .env) and also change the SHOW_LANGUAGE_SWITCH to be True
• commented out DEPLOY_HOST in settings_local since there wasn't a fallback
• prepend npm i [email protected] to the build development command to work around vue-tsc doesn't work with typescript 5.7.2 vuejs/language-tools#5018. (This will hopefully disappear in a few days.)
• visit the server at 0.0.0.0:8004

Next steps

A workaround is to comment out the last line of wsgi.py that calls update_from_db(), or updating the invalid tile value in pg directly. But regardless of the wisdom of that, there a few things to look into, some of which shouldn't be done in a patch?

• fix the values in these tiles (migration? in v8?)
• update the python SystemSettings to ignore this node (can do in a patch)
• stop creating values in these tiles (in v8?)

---

cc/ @aarongundel

[ekansa]

@jacobtylerwalls thanks for the deep investigation and diagnosis!

[jacobtylerwalls]

Throwing out ideas for better heuristics for "is the currently running Django project core arches itself?":

this should only evaluate True for running core arches, but it's a little fiddly:

>>> from pathlib import Path
>>> from django.conf import settings
>>> Path(settings.APP_ROOT).parent == Path(settings.ROOT_DIR)
True

[jacobtylerwalls]

Also worth looking into whether core urls.py can just do the same check that's working well in projects?

if settings.ROOT_URLCONF == __name__:

[jacobtylerwalls]

I'll open follow-ups for anything not addressed in 7.6.4.