Opened 17 months ago
Last modified 4 hours ago
#36022 assigned New feature
Name the main command django
| Reported by: | Ryan Hiebert | Owned by: | Ryan Hiebert |
|---|---|---|---|
| Component: | Core (Management commands) | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Ryan Hiebert, Frederich Pedersen | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
To aid in discoverability and compatibility with tools like uvx, change the name of the main command to django. Keep django-admin around indefinitely, with a message referring users to the new name.
Forum Discussion: https://forum.djangoproject.com/t/name-the-main-command-django/37230/14
External Implementation: https://github.com/ryanhiebert/django-cmd
Accepted DEP 16: https://github.com/django/deps/blob/main/accepted/0016-name-main-command-django.rst
Change History (11)
comment:1 by , 17 months ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:2 by , 17 months ago
| Triage Stage: | Accepted → Unreviewed |
|---|
comment:3 by , 17 months ago
| Resolution: | → wontfix |
|---|---|
| Status: | assigned → closed |
comment:4 by , 3 weeks ago
| Description: | modified (diff) |
|---|---|
| Resolution: | wontfix |
| Status: | closed → new |
| Summary: | make django an alias of django-admin → Name the main command django |
comment:5 by , 2 weeks ago
| Component: | Uncategorized → Core (Management commands) |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
| Version: | → dev |
comment:6 by , 6 days ago
| Cc: | added |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
I will try to look and this, and implement the accepted DEP.
comment:7 by , 6 days ago
| Owner: | changed from to |
|---|
Nevermind, I can see Ryan is in full swing at:
https://github.com/ryanhiebert/django/pull/2
Assigned correctly.
comment:8 by , 4 days ago
A little update on how this is progressing. I'm trying to be careful with the documentation, to keep it as compatible as possible. I'm trying to identify my best answer, but I'm not sure what the right balance is.
The current docs for the django-admin command are at docs/ref/django-admin.txt. That's used to construct the URL. Given that we're wanting to canonicalize on the new command, I'm looking to change that to docs/refs/django-cmd.txt. This raises an interesting question of how to deal with compatibility across different versions. It also has implications for how we should handle historical cross references to django-admin that shouldn't be changes, for example in release notes, but that we'd like to resolve to a useful page if possible.
One option is to eliminate the cross references in the release notes. Just say django-admin when we'd have a cross reference to the docs to the django-admin command docs, and accept that for those historical release notes, in the latest versions of the docs, they won't link anymore. The cross-referencing links will still work in earlier versions of the docs.
Another option is to keep the historical directive, and do a small amount of fancy footwork with sphinx so that the references remain visually intact with the prior command name, but actually point to the django-cmd docs.
I'm also investigating whether it might be possible to add a redirect between the pages. So visiting django-admin would still work, but would redirect to the new doc, or if that's too challenging to do with Sphinx we could have a simple documentation page that informs the reader that the command has been renamed and the docs have moved and give a link. Whatever approach worked out, we could even add the inverse to historical docs. The benefit is that the version switcher doesn't break. Maybe that's not worth the hassle of trying to redirect, I'm not sure.
comment:9 by , 4 days ago
| Has patch: | set |
|---|
comment:10 by , 2 days ago
| Patch needs improvement: | set |
|---|
comment:11 by , 4 hours ago
| Patch needs improvement: | unset |
|---|
Closing following my comment in the forum topic (since we need to triage somehow, and we can't accept this yet), we need to allow for more time for others to find the topic, read and comment. Let's revisit early Jan!