The preference seems to be for option 3, adding a new flag --exit. I have
implemented this and updated the pull request at
https://github.com/django/django/pull/3441.
On Wednesday, October 29, 2014 12:22:42 PM UTC+11, Tim Heap wrote:
>
> Hi all,
>
> I have created a ticket for this (
> https://c
My preference for this would be option 3., on the grounds that:
* I'd rule out 1 because of the slight backwards incompatibility (which
can affect people - I remember a deploy script failing because of a
changed exit code for a Mercurial command). In particular, currently
there are other condition
On Thursday 30 October 2014 15:22:01 Dan Poirier wrote:
> Wouldn't enabling this by default cause a problem for any automated
> deploys?
The discussion is about the makemigrations command, not migrate. The OP wants
to use it to find automatically if there are model changes not covered by
migrati
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 ne
If makemigrations exits with something other than 0, it will not have
created any migrations to run anyway, so running the makemigrations &
migrate pair here would not be affected. However, a useful one liner that I
have been using when developing is:
./manage.py makemigrations && ./manage.py m
I'm +1 on being able to continue using the line
./manage.py makemigrations && ./manage.py migrate
I can't see many (any?) situation where someone *wouldn't* run
makemigrations & migrate as one logical operation, whether by typing
the commands or running a script.
What would the workflow be where y
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
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
repr
The backwards compatibility issue I was thinking of is for people using
`makemigrations` in a script currently, expecting it to exit with 0 unless
something very wrong has happened. For example, if `makemigrations` is run
in a bash script with `set -e`, and it does not find any migrations, that
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" 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
> mom
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
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 applicat
12 matches
Mail list logo
