I also agree that users should opt-in to enabling the error, using option 2 or 3, but I will implement what ever the popular option is.
My argument regarding "As the command is instructed to make migrations, not making any is the error case." was more about when to return the error: either when changes *are* found, or when changes are *not* found. As the command is attempting to make a migration, not finding any changes is the exceptional case, and should return an error code (if enabled via flags, or however it will eventually work). On Thursday, October 30, 2014 10:30:50 AM UTC+11, Markus Holtermann wrote: > > I like the general idea, but I slightly disagree with "As the command is > instructed to make migrations, not making any is the error case.". Yes, > grep works that way but I thing this are two different use cases. I think > makemigrations on a project without any changes in the models' database > representation shouldn't exit with RC>0. I'd prefer to have the return code > either only set on dry-run or explicitly when using -e/--exit. I'm in favor > of 2. or 3. > > /Markus > > On Wednesday, October 29, 2014 8:44:31 AM UTC+1, Marc Tamlyn wrote: >> >> I agree number 1 is fine. For most general interaction with the command >> users won't notice. >> >> Marc >> On 29 Oct 2014 02:04, "Andrew Godwin" <and...@aeracode.org> wrote: >> >>> I'm actually fine with option 1 - always exiting with a status code if >>> no migrations are found. Since the status code does nothing useful at the >>> moment, I don't see any backwards compatibility issues, and as long as it's >>> a suitably small patch, it should be fine. >>> >>> (As for being surprising compared to grep, there are many other commands >>> with different exit codes one could draw parallels to; I'm not sure being >>> consistent with a very different utility is a worthwhile cause). >>> >>> Andrew >>> >>> On Tue, Oct 28, 2014 at 6:22 PM, Tim Heap <t...@timheap.me> wrote: >>> >>>> Hi all, >>>> >>>> I have created a ticket for this ( >>>> https://code.djangoproject.com/ticket/23728) but I would like some >>>> input before I work on it. I will copy the content of the ticket below for >>>> ease of reading: >>>> >>>> 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 greps >>>> -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. >>>> >>>> Regards, >>>> Tim >>>> >>>> -- >>>> 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 http://groups.google.com/group/django-developers. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/92203dcb-a775-4c17-a831-97d01ce8af3c%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/django-developers/92203dcb-a775-4c17-a831-97d01ce8af3c%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> 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-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/CAFwN1up96C8Daxn87Mt1y-TY%3DvGP_%3DTGaBRH6NZ9s5AQUu%3DL0A%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/django-developers/CAFwN1up96C8Daxn87Mt1y-TY%3DvGP_%3DTGaBRH6NZ9s5AQUu%3DL0A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> 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+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ff039c37-ab18-4047-97d3-366dbdb4c348%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
