#28398: Allow management command invocation to suggest for incomplete commands?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

#28398: Allow management command invocation to suggest for incomplete commands?

Vláďa Macek
Hi everyone,

I had an idea that would save me time working with Django:

The manage.py wouldn't only print "Unknown command" when incomplete subcommand name given, but also print those available by substring search.

https://code.djangoproject.com/ticket/28398

I added a screenshot and a patch there.

In my opinion, such first implementation could be as simple as that. Smarter versions may come later.

As suggested by Tim Graham (thanks, Tim), I resort here for opinions.

Thank you,

Vlada Macek

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5abdab10-e9e2-4dbd-81c7-ffd492781977%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: #28398: Allow management command invocation to suggest for incomplete commands?

Brice PARENT-2

Hi!

I'm not sure how I feel about that. It feels like a good idea at first, but it might lead to dangerous behaviours.

Let me explain my thought: having such a feature would encourage people to use it (of course). Doing so can lead so side effects. For example,  if, in a project you're working on, you want to use a custom management command named "migrate_data_to_other_server", you might end up typing "./manage.oy migrate" in hope for the system to display the exact name that you probably have forgotten. But it won't, it will migrate your database instead. What I mean is that executing commands that shouldn't work on purpose might lead to executing the wrong command instead. And management commands might be dangerous if not used at the right time (I've seen management commands being used to push code to production for example. Executing them by error in a dev environment might be a real issue!).

I'd prefer to encourage the use of "./manage.py help", which lists all available commands, or use masks when searching for a command ("./manage.py migrate*"). When you want to look for the name of a command, you'd know that adding a star somewhere won't execute anything other than listing available commands matching the value you just gave. And every developer knows (I think) how to use wildcards.

-Brice


Le 15/07/17 à 18:36, Vláďa Macek a écrit :
Hi everyone,

I had an idea that would save me time working with Django:

The manage.py wouldn't only print "Unknown command" when incomplete subcommand name given, but also print those available by substring search.

https://code.djangoproject.com/ticket/28398

I added a screenshot and a patch there.

In my opinion, such first implementation could be as simple as that. Smarter versions may come later.

As suggested by Tim Graham (thanks, Tim), I resort here for opinions.

Thank you,

Vlada Macek

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5abdab10-e9e2-4dbd-81c7-ffd492781977%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d67e85bc-c117-d527-d4f3-791782c15acd%40brice.xyz.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: #28398: Allow management command invocation to suggest for incomplete commands?

tom Tom
Vlada:
I think this is a great idea for improving the usability of manage.py, especially for newcomers. When I looked your current implementation used a simple 'in' to find suggestions, but this is not great for the most obvious/common use case: typos.

I would strongly advocate for using the levenshtein distance algorithm if this does get merged, there are some simple and succinct python implementations we can use, and the algorithm itself is what git uses to suggest commands (and I've always found that quite good).

Brice: 
You are right in that this is a case that could happen in part due to this feature, but it's a long shot and IMO the benefits outweigh the risks. This can happen without this feature anyway - if someone is typing in random manage.py commands without thinking then issues can and will arise. The only preventative measure we could take would be to add an "are you sure?" prompt after every manage.py invocation which is not a great idea overall.

For newcomers though this could be great, seeing the 'command not found' message can be confusing and unhelpful, any help we can add to that is a good thing IMO. Adding stars to the command invocation can be even more confusing as users have to escape them (and if they don't they could end up running random commands) and it's not terribly nice UI wise.

Built in shell autocompletion would be the best way forward in this case, at least for non-windows users. Kubectl has a nice way of doing this: source <(kubectl completion bash|zsh). Maybe something like this could be adapted for manage.py?


On 17 Jul 2017 08:49, "Brice PARENT" <[hidden email]> wrote:

Hi!

I'm not sure how I feel about that. It feels like a good idea at first, but it might lead to dangerous behaviours.

Let me explain my thought: having such a feature would encourage people to use it (of course). Doing so can lead so side effects. For example,  if, in a project you're working on, you want to use a custom management command named "migrate_data_to_other_server", you might end up typing "./manage.oy migrate" in hope for the system to display the exact name that you probably have forgotten. But it won't, it will migrate your database instead. What I mean is that executing commands that shouldn't work on purpose might lead to executing the wrong command instead. And management commands might be dangerous if not used at the right time (I've seen management commands being used to push code to production for example. Executing them by error in a dev environment might be a real issue!).

I'd prefer to encourage the use of "./manage.py help", which lists all available commands, or use masks when searching for a command ("./manage.py migrate*"). When you want to look for the name of a command, you'd know that adding a star somewhere won't execute anything other than listing available commands matching the value you just gave. And every developer knows (I think) how to use wildcards.

-Brice


Le 15/07/17 à 18:36, Vláďa Macek a écrit :
Hi everyone,

I had an idea that would save me time working with Django:

The manage.py wouldn't only print "Unknown command" when incomplete subcommand name given, but also print those available by substring search.

https://code.djangoproject.com/ticket/28398

I added a screenshot and a patch there.

In my opinion, such first implementation could be as simple as that. Smarter versions may come later.

As suggested by Tim Graham (thanks, Tim), I resort here for opinions.

Thank you,

Vlada Macek

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5abdab10-e9e2-4dbd-81c7-ffd492781977%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d67e85bc-c117-d527-d4f3-791782c15acd%40brice.xyz.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJPGZnaDNpXMOJzHq88j0vfnfZpk%2BnJQz3prtVVU5aeV1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: #28398: Allow management command invocation to suggest for incomplete commands?

Brice PARENT-2

I agree what I proposed wasn't either the best solution. It was more a workaround not to fall into the problem I mentioned.

Maybe then, when the command is not found, we could make something like the following (based on Vlada's work) :

$./manage.py passw
Unknow command "passw"
Would you like to look for commands looking like this? [Y/n] Y
Executing "./manage.py help | grep passw" (or "./manage.py search_command passw")
Candidate commands:
- changepassword [user]
- password
- setadminpassword

or something like that. It helps the user learn what he should use to look for a command's name instead of making user's errors a feature.

-Brice


Le 17/07/17 à 10:47, Tom Forbes a écrit :
Vlada:
I think this is a great idea for improving the usability of manage.py, especially for newcomers. When I looked your current implementation used a simple 'in' to find suggestions, but this is not great for the most obvious/common use case: typos.

I would strongly advocate for using the levenshtein distance algorithm if this does get merged, there are some simple and succinct python implementations we can use, and the algorithm itself is what git uses to suggest commands (and I've always found that quite good).

Brice: 
You are right in that this is a case that could happen in part due to this feature, but it's a long shot and IMO the benefits outweigh the risks. This can happen without this feature anyway - if someone is typing in random manage.py commands without thinking then issues can and will arise. The only preventative measure we could take would be to add an "are you sure?" prompt after every manage.py invocation which is not a great idea overall.

For newcomers though this could be great, seeing the 'command not found' message can be confusing and unhelpful, any help we can add to that is a good thing IMO. Adding stars to the command invocation can be even more confusing as users have to escape them (and if they don't they could end up running random commands) and it's not terribly nice UI wise.

Built in shell autocompletion would be the best way forward in this case, at least for non-windows users. Kubectl has a nice way of doing this: source <(kubectl completion bash|zsh). Maybe something like this could be adapted for manage.py?


On 17 Jul 2017 08:49, "Brice PARENT" <[hidden email]> wrote:

Hi!

I'm not sure how I feel about that. It feels like a good idea at first, but it might lead to dangerous behaviours.

Let me explain my thought: having such a feature would encourage people to use it (of course). Doing so can lead so side effects. For example,  if, in a project you're working on, you want to use a custom management command named "migrate_data_to_other_server", you might end up typing "./manage.oy migrate" in hope for the system to display the exact name that you probably have forgotten. But it won't, it will migrate your database instead. What I mean is that executing commands that shouldn't work on purpose might lead to executing the wrong command instead. And management commands might be dangerous if not used at the right time (I've seen management commands being used to push code to production for example. Executing them by error in a dev environment might be a real issue!).

I'd prefer to encourage the use of "./manage.py help", which lists all available commands, or use masks when searching for a command ("./manage.py migrate*"). When you want to look for the name of a command, you'd know that adding a star somewhere won't execute anything other than listing available commands matching the value you just gave. And every developer knows (I think) how to use wildcards.

-Brice


Le 15/07/17 à 18:36, Vláďa Macek a écrit :
Hi everyone,

I had an idea that would save me time working with Django:

The manage.py wouldn't only print "Unknown command" when incomplete subcommand name given, but also print those available by substring search.

https://code.djangoproject.com/ticket/28398

I added a screenshot and a patch there.

In my opinion, such first implementation could be as simple as that. Smarter versions may come later.

As suggested by Tim Graham (thanks, Tim), I resort here for opinions.

Thank you,

Vlada Macek

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5abdab10-e9e2-4dbd-81c7-ffd492781977%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d67e85bc-c117-d527-d4f3-791782c15acd%40brice.xyz.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJPGZnaDNpXMOJzHq88j0vfnfZpk%2BnJQz3prtVVU5aeV1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b1e1d1f7-c8c7-8c9e-7475-866027476434%40brice.xyz.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: #28398: Allow management command invocation to suggest for incomplete commands?

Adam Johnson-2
In reply to this post by tom Tom
I feel like this mostly duplicates the bash completion logic we have, which is also more standard across other CLI's

However I agree with Tom that correcting for typos is the main use case, using levehshtein distance is a good idea.

Another thing that some CLI's have, like npm or arc is auto-correction for common typos, e.g. ./manage.py mgriate could print out a message 'Assuming you meant migrate' and then continue executing migrate, not sure if this is the best for Django though where commands can be arbitrarily added by third party apps.



On 17 July 2017 at 09:47, Tom Forbes <[hidden email]> wrote:
Vlada:
I think this is a great idea for improving the usability of manage.py, especially for newcomers. When I looked your current implementation used a simple 'in' to find suggestions, but this is not great for the most obvious/common use case: typos.

I would strongly advocate for using the levenshtein distance algorithm if this does get merged, there are some simple and succinct python implementations we can use, and the algorithm itself is what git uses to suggest commands (and I've always found that quite good).

Brice: 
You are right in that this is a case that could happen in part due to this feature, but it's a long shot and IMO the benefits outweigh the risks. This can happen without this feature anyway - if someone is typing in random manage.py commands without thinking then issues can and will arise. The only preventative measure we could take would be to add an "are you sure?" prompt after every manage.py invocation which is not a great idea overall.

For newcomers though this could be great, seeing the 'command not found' message can be confusing and unhelpful, any help we can add to that is a good thing IMO. Adding stars to the command invocation can be even more confusing as users have to escape them (and if they don't they could end up running random commands) and it's not terribly nice UI wise.

Built in shell autocompletion would be the best way forward in this case, at least for non-windows users. Kubectl has a nice way of doing this: source <(kubectl completion bash|zsh). Maybe something like this could be adapted for manage.py?


On 17 Jul 2017 08:49, "Brice PARENT" <[hidden email]> wrote:

Hi!

I'm not sure how I feel about that. It feels like a good idea at first, but it might lead to dangerous behaviours.

Let me explain my thought: having such a feature would encourage people to use it (of course). Doing so can lead so side effects. For example,  if, in a project you're working on, you want to use a custom management command named "migrate_data_to_other_server", you might end up typing "./manage.oy migrate" in hope for the system to display the exact name that you probably have forgotten. But it won't, it will migrate your database instead. What I mean is that executing commands that shouldn't work on purpose might lead to executing the wrong command instead. And management commands might be dangerous if not used at the right time (I've seen management commands being used to push code to production for example. Executing them by error in a dev environment might be a real issue!).

I'd prefer to encourage the use of "./manage.py help", which lists all available commands, or use masks when searching for a command ("./manage.py migrate*"). When you want to look for the name of a command, you'd know that adding a star somewhere won't execute anything other than listing available commands matching the value you just gave. And every developer knows (I think) how to use wildcards.

-Brice


Le 15/07/17 à 18:36, Vláďa Macek a écrit :
Hi everyone,

I had an idea that would save me time working with Django:

The manage.py wouldn't only print "Unknown command" when incomplete subcommand name given, but also print those available by substring search.

https://code.djangoproject.com/ticket/28398

I added a screenshot and a patch there.

In my opinion, such first implementation could be as simple as that. Smarter versions may come later.

As suggested by Tim Graham (thanks, Tim), I resort here for opinions.

Thank you,

Vlada Macek

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5abdab10-e9e2-4dbd-81c7-ffd492781977%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d67e85bc-c117-d527-d4f3-791782c15acd%40brice.xyz.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJPGZnaDNpXMOJzHq88j0vfnfZpk%2BnJQz3prtVVU5aeV1g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1p%2B13mXN0BTM4BQwRDmZCHZjVAxsMwu%3DUCeYyXpmWhAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Loading...