Would it be good to have a `showtemplates` management command in Django?

Django Internals
1

Troubleshooting problems with TemplateDoesNotExist can be sometimes hard. So how about a management command that helps with that?

@jacklinke mentioned on mastodon [1], that he just wrote one himself [2].

I think like the coming show_urls/listurls management command [3], this would make a great addition to Django. If there is support for this I could ask @jacklinke for permission to bring it into Django?

[1] Jack Linke 🦄: "The `showtemplates` command lists all templates i…" - Social at jacklinke.com
[2] A management command to list all templates in the project. · GitHub
[3] Should the show_urls command be part of Django's standard library?

1 Like
2

I’ve written a similar list_templates command myself (mainly for configuring Tailwind… :sweat_smile:)

IIRC @oliverandrich incorporated it into the django-tailwind-cli package.

So I guess there’s some precedent for it being useful.

At what point we have to say that extra commands need to live outside of core, I can’t say. Historically Django-extensions more or less exists in order to house these kind of things without them needing to bloat the core package.

3

Carlton writes:

Historically Django-extensions more or less exists in order to house
these kind of things without them needing to bloat the core package.

I understand, but we’re about to get showurls into core, which is
already part of Django-extensions? So showurls is something that is
believed to be, generally speaking, in higher demand than
showtemplates and it would be more convenient to have it in core? And
as I mentioned in [1] the future of Django-extensions seems somehow to
be uncertain [2].

[1] Default automatic imports in the shell - #28 by e11bits
[2] Moving django-extensions forward · Issue #1892 · django-extensions/django-extensions · GitHub

4

:person_shrugging: :slight_smile:

The show urls discussion has been rolling along for several years, and built a considerable backing behind it. (Including me! :dancer:) The command also existed in django extensions ≈forever.

In contrast, despite having been using Django for some time, I only wrote my list_templates command in April 2023.

These kind of things are like template tags and database functions — we could keep adding them forever, but we need to decide where to stop at some point.

(I’m not taking a particular view here. IDK if a list_templates command in core is worth the maintenance or not.)

2 Likes
5

One of the things I like about some open source communities is knowing when to draw that line :+1: Django is one of those.

It would be a sad day if extensions becomes unmaintained. I hope it will be adopted by jazzband in that case.

6

Shouldn’t we make the error page better? A separate management command seems like it would hide the useful information instead of presenting it right there in the error page?

In iommi and django-fastdev we try to list all valid values on separate lines and in alphabetical order when there’s some invalid value given. Example output:

FastDevVariableDoesNotExist at /system/test/
asdasd does not exist in context. Available top level variables:

    DEBUG
    DEFAULT_MESSAGE_LEVELS
    False
    None
    True
    back_url
    bar
    base_url
    count
    csrf_token
    environment
    environment_color
    foo
    in_worker_pages
    list
    mapbox_access_token
    menu
    messages
    perms
    request
    sidebar_menu
    user

This type of error message is so useful that it’s often faster to write something incorrect on purpose, reload the page, see what is available and then continue; than it would have been to read the code to figure out what the correct value was.

1 Like
7

Carlton writes:

The show urls discussion has been rolling along for several years, and
built a considerable backing behind it. (Including me! :dancer: ) The
command also existed in django extensions ≈forever.

In contrast, despite having been using Django for some time, I only
wrote my list_templates command in April 2023.

These kind of things are like template tags and database functions —
we could keep adding them forever, but we need to decide where to stop
at some point.

(I’m not taking a particular view here. IDK if a list_templates
command in core is worth the maintenance or not.)

And David writes:

One of the things I like about some open source communities is knowing
when to draw that line :+1: Django is one of those.

Just some thoughts on this and then I’ll stop riding a dead horse here.

I think it’s good and necessary to draw a line somewhere. And that’s
easy. What’s hard is to define comprehensible criteria for
“somewhere”. And in my opinion, Django isn’t particularly better at it
than any other open source projects.

I know there is the “consensus” criteria, aka “cheering contest”. But
how good is that? Consensus is sought among a few active members of this
Django community, which I think is fair to say, don’t represent the vast
majority of Django users out there, looking at the daily downloads being
in the millions [1] and at almost two million other
projects/repositories depending on Django [2]. So there is always a huge
bias in a consensus.

But there is no alternative, right? And I think the current process
could work somehow better if consensus would be sought over “the overall
benefit for Django” rather than personal gusto. If I look at the
discussion about showurls for example, I just see “I want this”, “I
want this”, “Yeah, I want this”. So the outcome will likely make the
lives of these people easier, but not necessarily that of the majority
of Django users.

And rather discussing the addition of one management command, I could
see more value in a discussion about increasing the overall utility of
the whole tool belt, that is made of all management commands.

So soon Django has showurls for urls, nothing for templates and the
pretty useless findstatic for a single static file.

Alternatively an orthogonal set of commands like showurls,
showtemplates and showstatics (replacing findstatic) would at
least make more sense to me.

About bloat: I guess one’s man bloat is another man’s “batteries
included”? :person_shrugging:

And keeping a high bar for any addition to the core is just one way to
prevent bloat. Removing functionality with little value, like the
mentioned findstatic, could be another one.

[1] https://pypistats.org/packages/django
[2] Network Dependents · django/django · django repositories · GitHub

3 Likes
8

I think there’s a whole other discussion to be had here about how we manage proposals :sweat_smile:

There are many proposals ranging from tiny suggestions to large new features that I feel get lost in old threads - I’d like to see a place where they can all be listed and voted on, then have the steering council/whoever make decisions on.

9

I wrote on this exact topic last month:

1 Like
10

With the help of the gist above to list all templates I implemented better error messages for TemplateDoesNotExist in django-fastdev and released 1.13.0. A gist of what that does is here: Better TemplateDoesNotExist error · GitHub

I believe this change would make the management command not really needed and would help a lot of people.

1 Like
11

I don’t really think we need a show_templates and I definitely don’t think we should show every template in the error page.

What might be more useful is:

“No such template users/fo.html, did you mean users/foo.html?”

I would much rather have smarter errors than exhaustive ones or lists to manually check against.