Proposal: django project name

[Christian González]

Hi all,

I didn't find anything about that in the archive here, so I'd like to come to you with an idea which is either very dumb (please tell me) or I don't know why anyone hasn't thought about it...

I'm starting a bigger project with a self-created plugin system (GDAPS, alrady mentioned). Working nicely, but I came across a few Django shortcomings which are sometimes easy to workaround, but could be done better: the django project name.

TL;DR: Django has no (builtin/explicit) settings variable like PROJECT_NAME. Should have.

Long version:

If you have (like in my case) an application which is more than a single django app, and could have various 3rd party additions/plugins, there is no common sense of retrieving the overall "name" of the application. If you create a project using django-admin startproject myproject - the name says it, you name the project. It is written into various places, mostly comments etc.:

foo/asgi.py:ASGI config for foo project.
foo/asgi.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'foo.settings')
foo/settings.py:Django settings for foo project.
foo/settings.py:ROOT_URLCONF = 'foo.urls'
foo/settings.py:WSGI_APPLICATION = 'foo.wsgi.application'
foo/urls.py:"""foo URL Configuration
foo/wsgi.py:WSGI config for foo project.
foo/wsgi.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'foo.settings')
manage.py:    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'foo.settings')

But foo is no variable. Needers of this inofficial project name use workarounds like settings.ROOT_URLCONF[0] to get that name. But that's always a bit of a whacky feeling when I do it - doesn't seem like - "I'm sure this will be supported for the next 20 years".

When it comes to frontends, it's worse. In my case, my GDAPS module enables a Vue.js frontend, which needs a index.html which loads Vue. This file is (in SPA apps) the only file which is rendered using Django templates. No problem, put in gdaps' templates directory and go. Works fine, as long as the user of GDAPS is fine with my shipped index.html and the corresponding pre-defined url path that renders that index file using TemplateView.

If he wants to override that file using his own template (with maybe another font loaded etc.) I first thought I just change GDAPS to dynamically load the template in GDAPS' urls.py - but therefore it should know the name of the project it is a part of.

I can do that using a setting named PROJECT_NAME and place a url definition like

path("", TemplateView.as_view(template_name=os.path.join(settings.ROOT_URLCONF[0],"index.html")), name="app")

into urls.py. So the user can place an index.html into foo/templates/foo/ and it should work.

But as said, this seems to me as - hey, ROOT_URLCONF[0] - really, this is the project name?

path("", TemplateView.as_view(template_name=os.path.join(settings.PROJECT_NAME,"index.html")), name="app")

seems better to me.
I first thought that Django could provide that as "builtin" setting, but OTOH, explicit is better than implicit,
so why not
a) create a setting (which is created by django-admin createproject along with the other parsed templates) named
PROJECT_NAME o DJANGO_PROJECT_NAME
or
b) (because settings are not used in wsgi.py, manage.py etc.) create it earlier in the process - or does it have to be written at more than one places?
This would violate DRY.

Please tell me what you think about that.

Yours,
Christian

-- 
Dr. Christian González
https://nerdocs.at

[Adam Johnson]

Hi Christian

 

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.

When it comes to frontends, it's worse. In my case, my GDAPS module enables a Vue.js frontend, which needs a index.html which loads Vue. This file is (in SPA apps) the only file which is rendered using Django templates. No problem, put in gdaps' templates directory and go. Works fine, as long as the user of GDAPS is fine with my shipped index.html and the corresponding pre-defined url path that renders that index file using TemplateView.

If he wants to override that file using his own template (with maybe another font loaded etc.) I first thought I just change GDAPS to dynamically load the template in GDAPS' urls.py - but therefore it should know the name of the project it is a part of.

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/

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.

Thanks,

Adam

--
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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/37527e26-4e21-2684-5766-145441c6ae50%40nerdocs.at.

--

Adam

[Dan Davis]

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/
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.

Yes! And in apps designed to be re-used, this can be made really good with clever template design. I generally have *all* my templates extend a base template, so that my users can override one simple template, and reskin my pages simply -- assuming they use Bootstrap 3 4. So, mileage may vary.

I have also used drf-yasg, and other third party packages that provide reusable apps. It truly is not hard to override their templates, but as Adam is saying, you want to guide your users as to how to extend/embed and accommodate that.  What I describe above is only one such method.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0RGBfJft7RL4DSAp9WxJX_0v_D5J4m_exbF7XwC3t9tQ%40mail.gmail.com.

[magdy maher]

thank you for reply

Virus-free. www.avast.com

--

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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/37527e26-4e21-2684-5766-145441c6ae50%40nerdocs.at.

Virus-free. www.avast.com

[Christian González]

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.

[f.holop]

Christian González - Wed, 13 May 2020 at 22:13:34

> TL;DR: Django has no (builtin/explicit) settings variable like
> PROJECT_NAME. Should have.

4 of those were comments (i wish the project templates stopped doing that)

3 of those were env variables which a deployment can override with
an actual environment variable anyway...


introducing variables/constants into the settings/etc can help but
sometimes it also makes it more rigid and cluttered. it's a balancing
act that has a different sweet spot for everyone.

but there is nothing stopping you from using one. i do.

some other potential uses:

- logging setup
- ADMINS
- FORMAT_MODULE_PATH

-f
--