Re: Contributing to a module that does not seem to be covered by tests extensively (djanog.db.models.expressions)

Hi David, Unfortunately we've missed the cutoff for 1.9, this will have to wait to be released with 1.10. I didn't want to delay the beta date with what could potentially be a drawn out patch (validating names, locations of classes, accuracy of docs). Further, we probably shouldn't have added

Re: makemigrations --exit; exit status feels backwards from conventions

In your case, successfully creating a migration indicates a failure. Why do you object to using a ! to communicate this? ! ./manage.py makemigrations -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To

Re: makemigrations --exit; exit status feels backwards from conventions

On Tue, Oct 20, 2015 at 1:48 PM, Jon Dufresne wrote: > On Tue, Oct 20, 2015 at 1:18 PM, Shai Berger wrote: >> On second thought, I take that back. >> >> As is evident from the discussion Jon cited[1], the --exit flag was intended >> to >> be used as

Re: makemigrations --exit; exit status feels backwards from conventions

On Tuesday 20 October 2015 20:09:36 I wrote: > On Tuesday 20 October 2015 19:51:36 Marc Tamlyn wrote: > > I see what you mean and the inherent problems with the design. However > > fundamentally the command you are running is "make some migrations", and > > the "I don't have any to make" step is

Re: makemigrations --exit; exit status feels backwards from conventions

On Tuesday 20 October 2015 19:51:36 Marc Tamlyn wrote: > I see what you mean and the inherent problems with the design. However > fundamentally the command you are running is "make some migrations", and > the "I don't have any to make" step is clearly an error case, not a success > case. In

Re: makemigrations --exit; exit status feels backwards from conventions

I see what you mean and the inherent problems with the design. However fundamentally the command you are running is "make some migrations", and the "I don't have any to make" step is clearly an error case, not a success case. In particular it would be very wrong for the real "I want to make some

Re: Fellow Report - October 17, 2015

This is awesome news for Django's status in enterprise, great work everyone. I hope something comes from the Microsoft Fellow concept, that would be brilliant. On 20 October 2015 at 15:18, Michael Manfre wrote: > > On Tue, Oct 20, 2015 at 3:02 AM, Aymeric Augustin < >

Re: Fellow Report - October 17, 2015

On Tue, Oct 20, 2015 at 3:02 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > 2015-10-20 5:04 GMT+02:00 Michael Manfre : > >> My long term plan is to switch out ADO for replaceable ODBC and FreeTDS. >> This may follow the current pattern Aymeric started when

Re: Ticket #25328 - LiveServerTestCase with HTTPS - opinions?

The argument that adding LiveServerTestCase with HTTPS as a separate tool is easy - it is valid in this case, after my refactor has been merged. The real use-case when I (and someone else may) need HTTPSLiveServerTestCase is the one I wrote before: - in a HTTPS-only application you can use

Re: should manage.py test run system checks?

2015-10-20 2:48 GMT+02:00 Tim Graham : > me: I'm of the opinion that running the system checks as part of the manage.py > test command should be opt-in (for example, by writing a test that > asserts the call_command('check') output is empty. For example, when > debugging a

Re: Fellow Report - October 17, 2015

2015-10-20 5:04 GMT+02:00 Michael Manfre : > My long term plan is to switch out ADO for replaceable ODBC and FreeTDS. > This may follow the current pattern Aymeric started when he created > django-pymssql, or have them both in django-mssql. For the record, django-sqlserver