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
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.
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 django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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 django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d67e85bc-c117-d527-d4f3-791782c15acd%40brice.xyz.
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
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJPGZnaDNpXMOJzHq88j0vfnfZpk%2BnJQz3prtVVU5aeV1g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1p%2B13mXN0BTM4BQwRDmZCHZjVAxsMwu%3DUCeYyXpmWhAg%40mail.gmail.com.