Command shortcut aliases

[shangxiao]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

Add shortcuts to common commands:

• mm for makemigrations
• sm for showmigrations
• m for migrate
• rs for runserver

Problem

For folks who work mostly from terminals, forming shortcuts to everyday tasks is often regarded as essential for productivity & sanity, relieving you from tedium.

Eg having to type out ./manage.py showmigrations <app-name> can start to be a drag.

Note It's extremely simple to setup (see below); am adding this request in case folks wish to see this added to core 🤷‍♂️ If you want to vote no because of its simplicity then that's a good reason 👍

Note Note Tab completion of commands has existed for some time now but I've not had a good experience with it. I've personally found it to be not fast enough for it to be productive. Additionaly tab completion needs to have an unambiguous prefix to wholly complete. Compare this with the speed of typing mm.

Request or proposal

request

Additional Details

It's actually extremely simple to setup your own shortcuts and I've started setting this up on most projects I start working on: https://github.com/shangxiao/stupid-django-tricks/tree/master/management_command_alias

In manage.py

def alias_map(argv):
    if len(argv) > 1:
        argv[1:2] = settings.COMMAND_ALIASES.get(argv[1], argv[1]).split(" ")
    return argv

if __name__ == "__main__":
    execute_from_command_line(alias_map(sys.argv))

In your settings:

COMMAND_ALIASES = {
    "mm": "makemigrations --no-header",
    "sp": "shell_plus",
    # ... etc ...
}

Aliasing manage.py

Though this is possibly outside the scope of this request (though I think as part of Django would make other folks' lives easier), I shell alias ./manage.py with dj so my daily routine becomes effortless:

$ dj sm app<tab-completion>
$ dj mm
$ dj m
 ... etc ...

Implementation Suggestions

No response

[github-actions]

Thank you shangxiao for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[tim-schilling]

There are a lot of solutions out there on how to do this. I'm not quite sure what would be best. What would happen for other commands, could you redefine it's shortcut? Would it automatically determine the shortcut or would it have to be specified in code?

As a tangent, I believe django extensions supports tab auto complete which is in the same realm.

[shangxiao]

Just FYI for folks wanting to discuss this: I'm not interested in engaging further and am unsubscribing.

But please do feel free to discuss and vote whatever.

If it gets accepted awesome, a beginner wanting to get started can pick it up 🎉

If it doesn't then I don't care as I already have my way of doing it 🤷‍♂️

[andrew-cybsafe]

There's lots of prior art in this idea, so I feel that it's reasonable for Django to support aliases. There are various flavours of how aliases are implemented, so we should consider carefully how we'd like them to work.

For example, Git has a comprehensive aliases system, but it can only be configured locally on a per-user basis. Bash, zsh et al. also allow aliases, but again these are typically defined by a user for their sole use.

The rails command line also supports aliases, but these are fixed and cannot be edited on a per-user basis. In my opinion, this is a nice way to implement as it maintains the standardisation across projects, i.e. 'rails s' will always start a Rails server. So if we go ahead with this, I'd prefer fixed aliases.

[knyghty]

I had a very brief look into this. I think it might not require too much code if we can use add_parser(). However I'm not sure what the lift is to achieve this since we don't currently use add_parser() at all.

This wouldn't be as easily user-configurable though.