Add a management command to list URL patterns

[Martín Peveri]

It would be practical to visualize all the urls of the application in a command, is it possible?. If it is not possible, it is something like this:

python manage.py routes

[Tim Graham]

​django-extensions has a show_urls command which "produce a tab-separated list of (url_pattern, view_function, name) tuples for a project." I'm not sure that this needs to be incorporated into Django itself.

[Martín Peveri]

I understand, but I depend on an extension. Tell me if you consider it to integrate it into the framework and I could send an RP. Thanks!

[Keryn Knight]

Can I suggest that its worth taking to the developers mailing list to discuss this possibility? As an anecdotal datapoint, I know I semi-frequently make use such a command when coming into a project which I've not previously been heavily involved with. The flat output (vs traversing a list of include() usages) gives a decent overview on what's what, and the contrib.admindocs package already provides a similar overview if installed into the admin.

It also isn't a huge amount of new work (in my mind, because ​I wrote a similar thing to the django-extensions command) precisely because it can depend on the same functions admindocs does. So the maintenance burden is arguably mostly already in place.

[Martín Peveri]

I think what Keryn Knight said is good. If approved, I could work on the ticket and send a PR.

[Tim Graham]

Someone could try to get a consensus on the DevelopersMailingList about this. I've never had a need for it myself. A rough criteria I've used for thinking about whether or not something should be in core is whether 80% of projects use it. The existence of an implementation in django-extensions demonstrates this can live as a third-party library which seems sufficient to me.

[Carlton Gibson]

Discussion at DjangoCon US 2022 suggests it would be a popular enough feature.

[Natalia Bidart]

​Link to post in the forum where consensus seems quite clear.

[Xavier Tilley]

I have the feature finished I just haven't had time to finished up the tests and documentation. Hopefully my day job will slow down a bit and I can get a PR in next month.

[Alexandr Artemyev]

Replying to Keanya Phelps:
Not sure if this change was made intentionally or by mistake.

Replying to Xavier Tilley:

I have the feature finished I just haven't had time to finished up the tests and documentation. Hopefully my day job will slow down a bit and I can get a PR in next month.

Do you still plan to make these changes?

Replying to Adam Johnson:
Could we push this feature?

[Chris Rose]

I've picked up the work started by Xavier Tilley and pushed a bit more onto it.

[Ülgen Sarıkavak]

I've pinged Chris under the Github issue and with ​his approval, I'm taking the task. My plan is, first to consider which formatting options are needed, then to push the finalized version this weekend.

Replying to Chris Rose:

I've picked up the work started by Xavier Tilley and pushed a bit more onto it: ​https://github.com/django/django/pull/18347

[Ülgen Sarıkavak]

The PR is ready to be reviewed 🙌🏻

[Ülgen Sarıkavak]

I'm a bit confused about who should set the "Ready for checkin" flag. The current info box on this page says

For a Django committer to do a final review of the patch and merge it if all looks good.

so I thought this is the correct state to be in but now the issue is no longer visible under https://code.djangoproject.com/query?status=!closed&needs_better_patch=0&needs_tests=0&needs_docs=0&has_patch=1&stage=Accepted&desc=1&order=changetime so I guess I shouldn't have touched that flag. Considering

If you’re really not certain if a ticket is ready, don’t mark it as such.

warning from ​https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/#be-cautious-when-marking-things-ready-for-check-in , I'm changing that flag back.

Sorry for the extra notifications going to the followers of the issue.