Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#33320 closed Uncategorized (invalid)

Inconsistencies around --no-input flags

Reported by: Peter Law Owned by: nobody
Component: Core (Management commands) Version: 3.2
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I realise this is a really small thing, but I get gotcha'd by it quite a lot.
Some Django commands take a --no-input flag while others take a --noinput flag. This means that rather than being able to just type a spelling you've learned, you need to look it up for each command (or try it and have it fail).

Given that --no-colour has the interstitial dash, I suggest consolidating around that spelling (i.e: --no-input) for consistency, but I don't feel strongly as long as there's only one spelling of the no-input flag.

It even seems reasonable for a while for Django commands which currently accept the "other" spelling to accept both (perhaps with a warning), so there's a good upgrade path here for people or scripts which are used to the current arrangement.

Change History (2)

in reply to:  description comment:1 by Mariusz Felisiak, 3 years ago

Component: UncategorizedCore (Management commands)
Easy pickings: unset
Resolution: invalid
Status: newclosed
UI/UX: unset

Some Django commands take a --no-input flag while others take a --noinput flag. This means that rather than being able to just type a spelling you've learned, you need to look it up for each command (or try it and have it fail).

All built-in commands accept both --noinput and --no-input since Django 1.9.

comment:2 by Peter Law, 3 years ago

Oh, sorry. drop_test_database was the one I'm hitting this on. I'd assumed that that was a built-in, though it turns out not to be (it's in django-extensions). Sorry about that.

Note: See TracTickets for help on using tickets.
Back to Top