#23728: sys.exit(1) from makemigrations if no changes found
-------------------------------------+-------------------------------------
Reporter: tim_heap | Owner: nobody
Type: New feature | Status: new
Component: Core (Management | Version: 1.7
commands) | Resolution:
Severity: Normal | Triage Stage:
Keywords: migrations | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by tim_heap):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Old description:
> It would be very useful for continuous deployment, testing, commit hooks,
> and other applications if `django-admin makemigrations` signaled via an
> exit code if any migrations were found. Commits in projects could be
> rejected if migrations were outstanding, continuous deployment systems
> could fail the build on outstanding migrations, and potentially other
> uses. No more would hasty commits break things when developers forgot to
> make migrations!
>
> Changes to the code to make this happen are easy enough, but I am unsure
> how the command should behave. The `grep` unix utility is a example to
> copy. Under normal operation, `grep` always exits `0` unless an error
> happens, regardless of whether it found any matches. Invoking grep with
> the `-q`/`--quiet` flag causes grep to be silent, not printing anything,
> as well as exiting `0` if matches are found and `1` if nothing is found.
>
> I am proposing `django-admin makemigrations` should exit with `1` (or
> anything non-zero) if no migrations to make were found, or exit `0` if
> migrations to make were found. As the command is instructed to make
> migrations, not making any is the error case.
>
> I am unsure how this new functionality should be selected by the user
> when invoking `makemigrations`. The options I see are:
>
> 1. Enable this always. This is very simple to implement and easy to
> understand. Good unixy tools use error codes extensively to signal
> errors. This may be surprising behaviour when compared to `grep` though,
> and breaks backwards compatibility in a minor way.
> 2. Enable this when the `--dry-run` flag is enabled. Now this flag can be
> used to check for migrations that need to be created both visually via
> the printed text, and composed in shell commands.
> 3. Add a new flag `-e`/`--exit` (or similar). The sole purpose of this
> flag would be to exit with `1` when no migrations were found.
> 4. Add a new flag `-q`/`--quiet` that copies the behaviour of `grep`s
> `-q`/`--quiet` flag: silences output and exits with `1` when no
> migrations were found. This duplicates functionality though, as logging
> can be silenced using `-v0` already.
>
> My personal preference is for option 2. I was surprised when enabling
> `--dry-run` did not signal its result via the exit code. 3 would be the
> cleanest and most composable option, as 4 could be emulated using `-ev0`.
>
> I will implement this change using 2, unless other people have opinions
> on the matter.
New description:
It would be very useful for continuous deployment, testing, commit hooks,
and other applications if `django-admin makemigrations` signaled via an
exit code if any migrations were found. Commits in projects could be
rejected if migrations were outstanding, continuous deployment systems
could fail the build on outstanding migrations, and potentially other
uses. No more would hasty commits break things when developers forgot to
make migrations!
Changes to the code to make this happen are easy enough, but I am unsure
how the command should behave. The `grep` unix utility is a example to
copy. Under normal operation, `grep` always exits `0` unless an error
happens, regardless of whether it found any matches. Invoking grep with
the `-q`/`--quiet` flag causes grep to be silent, not printing anything,
as well as exiting `0` if matches are found and `1` if nothing is found.
I am proposing `django-admin makemigrations` should exit with `1` (or
anything non-zero) if no migrations to make were found, or exit `0` if
migrations to make were found. As the command is instructed to make
migrations, not making any is the error case.
I am unsure how this new functionality should be selected by the user when
invoking `makemigrations`. The options I see are:
1. Enable this always. This is very simple to implement and easy to
understand. Good unixy tools use error codes extensively to signal errors.
This may be surprising behaviour when compared to `grep` though, and
breaks backwards compatibility in a minor way.
2. Enable this when the `--dry-run` flag is enabled. Now this flag can be
used to check for migrations that need to be created both visually via the
printed text, and composed in shell commands.
3. Add a new flag `-e`/`--exit` (or similar). The sole purpose of this
flag would be to exit with `1` when no migrations were found. This could
be combined with --dry-run to just check for migrations that need to be
made.
4. Add a new flag `-q`/`--quiet` that copies the behaviour of `grep`s
`-q`/`--quiet` flag: silences output and exits with `1` when no migrations
were found. This duplicates functionality though, as logging can be
silenced using `-v0` already.
My personal preference is for option 2. I was surprised when enabling
`--dry-run` did not signal its result via the exit code. 3 would be the
cleanest and most composable option.
I will implement this change using 2, unless other people have opinions on
the matter.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/23728#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.c1f9c5f2823fc63c67ef03ce5701b053%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
