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 a
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 uns
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 Marc's --check. Jon is basically correct in hi
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 Marc's --check. Jon is basically correct in his analysis, and I
> think the root issue is that "--exit" is
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 cl
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 particu
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 mi
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 <
> aymeric.augus...@polytechn
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 he created
>> django
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 c
Just brainstorming : by all of the above, it would seem that the best default
is to run checks unless specific tests are selected. Of course, this could be
perceived as inconsistent, and that would be a problem.
On 20 באוקטובר 2015 10:04:17 GMT+03:00, Aymeric Augustin
wrote:
>2015-10-20 2:48
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 single test, it doesn't
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 did that as well. In d
13 matches
Mail list logo