The django-extensions library has a fantastic management command called show_urls which will print all of the urls in your project. This is an extremely helpful debugging tool when dealing with URL routing issues. At the same time, it seems like it’s a somewhat unknown tool.
I’d like this to be included. I don’t always have Django-extensions installed, but I often deliberately hit the 404 page in order to get the list of URLs patterns displayed. Being able to just do that at the CLI would save a bit of silliness there. (So a +1 from me.)
This was Someday/Maybe for a long time, but I moved it to Accepted during DjangoCon US 2022, because there was a discussion about it expressing all/multiple positives.
While I can’t say that I use it weekly or monthly, when I need it, I go out of my way to install django-extensions if it’s not already installed in a project to use it.
Otherwise, I have to go deep into a project’s code to try and figure out what some third-party package may or may not have named their URL path. Even then, you must still know the names space if it’s passed to the path or a router name.
So, show_urls solves an unobvious problem that I’m unsure how else to figure out.
Currently I do the exact same thing that Carlton described, particularly I always use http://localhost:8000/foo/ to get there. The day that a 3rd party app decides to provide a valid view under foo I’m doomed!
I use show_urls regularly and find debugging URL matches one of the more frustrating parts of Django development. In several projects I’ve either installed django_extensions temporarily or copied the code to a live console at some point.
Strong +1 to include functionality like this in Django-proper – it doesn’t seem too complex, depending on if we want all the different output options etc.
2. Do you use it regularly?
Yes, more than any other management command. Especially after black took over the world, it’s become hard to quickly “scan” the URL structure by just looking at the code, so having it in table form is very useful.
3. Do you feel like Django’s standard library should contain a similar command?
Yes, although it could probably be acceptable to only output CSV, for further processing by other commands like xsv.
The work for this has been moving forward. Here’s the current PR. @ulgens has been working on this recently .
The currently proposal includes a number of different outputs. There’s five options and some are available in colour/no-colour options. I’d like to bring the discussion on outputs to the forum to discuss the options, with two key questions:
Feedback on the number of options. Is 5 too many/few, and which would you like to see included?
For the format that you would like included, any specific feedback on that?
To add to this. One project I worked on in the past had a way of labeling routes as “public URLs” and we’d dump them as a JSON structure for our frontend code to consume.
If this command existed, I think we would have tried to override the Command in the PR to filter down what we wanted. I would want to be able to filter down what URLs are included, and added extra fields to the input.
I added comments to the PR on how we could get that (at least when it comes to JSON output).
I think we don’t necessarily need to support so many
We should be have an accessible option. See some stuff on accessibility here
I think the json option and maybe the “verbose” option (if we removed the -----) might be the most accessible. I don’t think we necessarily need to give the accessible version by default (@accessibility could you have a think here and give some feedback?)
I don’t think we need to give 5 formats out of the box and I would be tempted to remove a couple (need something accessible, something json, and something to list - so maybe 2-3 options).
Very nice, I’ll personally be using this a lot once it’s available!
Thinking about the formats, you can probably simplify by just keeping the aligned, verbose and pretty-json variants.
pretty-json can serve the same purpose as json – being machine readable and useful for shell piping and scripts – while still being easy to read.
Since aligned already looks nice, table doesn’t bring too much extra value - especially since the user has to remember it exists and opt into it. It’s also easy for table drawing characters to cause a mess when resizing terminals in a way the aligned format avoids by just being line based.
.
