Re: sys.exit(1) from makemigrations if no changes found

[Dan Poirier]

Wouldn't enabling this by default cause a problem for any automated
deploys?  Ours typically run the migrate command on every deploy, just
in case there are new migrations, and any command that returns a non-0
exit status is going to look like a deploy failure.

Having the behavior change with a new command line option would be just
fine.

Dan

On Wed. 2014-10-29 at 03:44 AM EDT, 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  o5...@public.gmane.org> 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-developers+unsubscribe-/
> jypxa39uh5tlh3mboc...@public.gmane.org.
> To post to this group, send email to 

Re: Django Trac ticket keywords

[Dan Poirier]

On Thu. 2013-08-29 at 06:15 PM EDT, "Daniele Procida"  wrote:

> Would there be any objection if I used a keyword ("afraid_to_commit"
> or something) to mark tickets that I think would be suitable for
> first-time committers doing the "Don't be afraid to commit" tutorial
> to tackle?

My first reaction to that keyword name is "I should be especially afraid
to commit this ticket". Not sure that's the intention.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: upgrading the choices machinery for Django

[Dan Poirier]

I like this - it solves something that's always bugged me.

One nice addition would be to specify explicitly what .id a particular
Choice should have. It would be useful in converting existing code that
might not have chosen to number its choices the same way this proposal
does by default. It looks like you could use Choices.Group(n-1) to make
the next choice defined use id=n, but that's not very elegant.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Cleaning up manage.py and import paths

[Dan Poirier]

On Mon. 2011-10-10 at 06:05 PM EDT, Carl Meyer  wrote:

> In the spirit of making Django behave better as a Python library (c.f.
> Glyph's keynote at djangocon.us), I'd like to finally tackle removing
> the sys.path hacks in django.core.management.setup_environ.

Yes!  I can't wait.  I cannot count the hours I wasted in confusion
caused by these inconsistencies.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Suggestion: a new "nature" field in Trac

[Dan Poirier]

On Mon. 2011-03-28 at 03:07 AM EDT, Russell Keith-Magee 
 wrote:

> One
> possibility: have two 'bug' options -- "Bug" and "Release-blocking
> bug". Easy to filter on, relatively easy to understand, and easy to
> correct if it gets mistriaged.

Apache HTTP Server uses a Severity field, with values ranging from
Blocker and Critical down to Trivial and finally Enhancement. I don't
think the full range ever gets used (what's the difference between Minor
and Trivial?) but it's definitely useful to be able to mark a bug as
Blocking or Enhancement.

Full list:
blocker
critical
regression
major
normal
minor
trivial
enhancement

Dan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.