-
Notifications
You must be signed in to change notification settings - Fork 88
Add django command #100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add django command #100
Conversation
shaib
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can mitigate some of the "multiple spelling" issue, by having django-admin not as a completely equivalent alias to django, but as a thin wrapper that invokes django and prints a message along the lines of
The
django-admincommand is being renamed todjango. You can keep using either name, they are equivalent except for the printing of this message. For more details on the naming change, see (link to DEP 100).
746ba9e to
af198fb
Compare
Thanks for that suggestion. I've worked it in. I think it'll make it a little easier to start any discussion about it. |
RealOrangeOne
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love this idea ❤️
84252b1 to
5a96652
Compare
| Others have had difficulty identifying | ||
| the correct ``uvx`` (``uv tool run``) command as | ||
| ``uvx --from django django-admin`` | ||
| instead of ``uvx django-admin`` or ``uv django``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean uvx django ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes!
| Motivation | ||
| ========== | ||
|
|
||
| Django is how many people first learn Python, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this completely anecdotal, or do we have any data points from a survey?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could add it to future surveys if more people think it'd be a useful data point.
My data point is asking while on the stage at DjangoCon US and seeing over half the room hold up their hands every time I ask them if they learned Python by learning Django.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. I feel like this mention is worth having a reference for, but I guess it's too late now.
| It is a common tripping point for folks on the forum to see | ||
| ``No module named django-admin`` | ||
| because they try to run ``python -m django-admin``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a total of 13 questions asked, for 3600+ views starting back in 2016. Typically, I would say this is small, but if we look at it from the perspective of first-time django devs, it seems to be common enough for us to improve.
- https://stackoverflow.com/search?q=%22No+module+named+django-admin%22
- https://forum.djangoproject.com/search?q=%22No%20module%20named%20django-admin%22
- https://groups.google.com/g/django-users/search?q=%22No%20module%20named%20django-admin%22
- Django Discord shows 6 questions with
"No module named django-admin" - Python Discord shows 1 question with
"No module named django-admin"
| Backwards Compatibility | ||
| ======================= | ||
|
|
||
| The existing ``django-admin`` command will remain indefinitely |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I'd like to see this not be the case. Having the message when people use django-admin, but never planning on removing it feels like unnecessary noise. [Or have the warning message removed until we have a plan in place. Otherwise we're going to end up with another setting to disable that messaging.]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are competing community values that I'm trying to navigate:
- Introduce the preferable spelling,
django - Avoid breaking existing material that uses
django-admin - Have only one way to do it
- Avoid noisy warnings that don't have a clear time horizon
I don't see a way to have all four of these at the same time. If we skip the warning, we have more than one way to do it. If we set a clear duration on the warning then we will break existing material at that point in the future.
The persistent warning without a time horizon felt like a reasonable way to soft-enforce "one way to do it" without breaking existing material; adding a setting could further soften the enforcement. The warning is visible to developers using Django, without breaking any commands. That can give us some time to have a better sense of whether the community will ever want to remove the old way, or whether we'd rather compromise on "only one way to do it".
If the project is prepared to make that choice now rather than wait, I'm happy for that. I think that my preference would be the same as yours: let's plan to remove it at some specific point in the future. It might deserve a longer deprecation period due to the centrality of the command, although I think I'd personally be inclined stick with the policy as stated.
I suspect this DEP won't be able to be resolved without the SC determining the right way to balance these competing values, because key members of the community disagree on which values should have the highest priority for this question. Would it be best for the purpose of lining this question up for the SC to modify this DEP with a more aggressive deprecation suggestion, or keep it as-is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy with either the current proposal or with setting an explicit timeline, though I think it should be longer than our usual deprecation cycles to allow the tutorial ecosystem to migrate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to phasing django-admin out over a really long time. I agree with Tim that we should have an appropriate warning message, but my gut feel is that we should phase it in a bit slower than we might otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm +1 for keeping django-admin indefinitely. pytest still has its legacy py.test command with no plans to deprecate, and it doesn't seem to harm users. What does hurt is when production scripts with no version control break due to the command going missing. In such cases, deprecation warnings are often never seen because they're piped into ignored logs.
But I'd also be okay with something quite long-term, like "After two major versions, it will be deprecated" would be okay. We can use language similar to Python 3.14's announcement of the new compression module:
Any deprecation or removal of the existing compression modules will occur no sooner than five years after the release of 3.14.
nanuxbe
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As others have mentioned, my only concern with this is the lack of planned deprecation for the django-admin command.
I agree that this will need non-standard, longer term deprecation than the usual, so it might be best to come up with that in a separate PR/discussion/place
LilyFirefly
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This DEP is now accepted. All members of the Steering Council are in favour (I've spoken with @carltongibson in person).
@ryanhiebert @knyghty Can one of you make the requested changes to this PR? Then it can be merged.
This comment was marked as resolved.
This comment was marked as resolved.
tim-schilling
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I technically approved in Slack. All good here.
Assign the DEP number Co-authored-by: Lily <[email protected]>
Assign the DEP number Co-authored-by: Lily <[email protected]>
It has been accepted! Co-authored-by: Lily <[email protected]>
|
Amazing, thank you everyone! |
|
Amazing, I’m looking forward to this change 🙌🙌 |
Motivated by a desire to remove confusing papercuts in Django and to follow common convention in the Python ecosystem, this DEP proposes to add a new
djangocommand equivalent to the existingdjango-admincommand, and to update the documentation to prefer this new spelling.Forum discussion
Rendered