Hi Adam, > > TL;DR: Django has no (builtin/explicit) settings variable like > PROJECT_NAME. Should have. > > > I can see how it would be useful in several situations. But in most > long-lived projects I've come across, the "project name" is different > to the website name (or names, plural, if it has evolved into multiple > brands). Additionally, there's already the ability for a "Site name" > through the contrib.sites framework, and translations complicate the > idea of a single name. I'm not sure /another/ axis of naming would > make things easier. Sticking to Python imports and file paths to glue > together things in code seems favourable.
Definitely, that's the problem. I didn't mean "Site name" - which corresponds to maybe "project title" in my project. This would be translatable too. I meant a machine name, namely the python module which IS the main project. Maybe name it DJANGO_PROJECT_MODULE etc. > Wherever you place the template, users can already override it by > creating one in their project with the same name, in an app that > appears first in INSTALLED_APPS. There's a documentation page on this > topic: https://docs.djangoproject.com/en/3.0/howto/overriding-templates/ Not possible. In my case, GDAPS already IS a reusable app (which enables plugins for Django). So this app is included in INSTALLED_APPS already in a certain position, and the whole application using this lib could consist of plenty of plugins (which are Django apps too). GDAPS dynamically collects them at server start and adds it to INSTALLED_APPS - but yes, *after* GDAPS. so they can't override any of GDAPS' templates. > > Alternatively, you can tell users to install their own URL mapped to > their own override template. It would only be one line of > configuration, the same as using include() to include your URLconf. > And it would allow users to serve your app at multiple URL's or with > more complicated patterns. That would be a possibility. But agian, only if the app providing this urlpattern comes *before* my GDAPS framework in INSTALLED_APPS. which is not possible except I inject all the plugins before GDAPS into INSTALLED_APPS. But that's my own implementation problem and should not be theme on this list here. The problem is that GDAPS does not know HOW the project GDAPS is a part of will be named. And the only way I found a possibility was to make it dynamic within GDAPS: https://gitlab.com/nerdocs/gdaps/-/blob/master/gdaps/frontend/urls.py So I need to know how the project is named. And as I saw that Django just hardcoded this name when creating a new project, and questions about how to get the Django project name out of a project (https://stackoverflow.com/questions/11179204/how-do-i-find-my-project-name-in-a-django-project) end up in either taking ROOT_URLCONF[0] (which is bad IMHO, see possible dynamic nature like https://code.djangoproject.com/ticket/31527). So I thought that Django providing a project name (which IS the import path of the main application) would be a good idea. Anyway, my own project will require a PROJECT_NAME variable, because of this template overriding problem. 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/d67cacb5-6c62-8551-b8e9-16e55f644dbf%40nerdocs.at.
pEpkey.asc
Description: application/pgp-keys
