I don't have a strong opinion on a nested structure for the tests; I merely
followed the existing convention for contrib tests that were already in
tests/. Note that if we do nest, we still need the "_tests" suffix (or some
distinction so to prevent duplicate app_labels from the contrib apps
th
On Monday 09 February 2015 02:01:03 Russell Keith-Magee wrote:
>
> The only other thing I'd flag is that if any of these aggregates are recent
> additions (e.g., added in Postgres 9), the failure mode for earlier
> versions should be relatively clean.
>
Nitpick: Django 1.8 -- the first to have dj
On Monday 09 February 2015 17:38:27 Markus Holtermann wrote:
> I'm +1 on moving the contrib tests to tests/_tests/ .
>
I'm +1 on preventing tests from being packaged with the contrib apps;
I'm also +1 on moving them out of the app folders in the source -- +0 for the
move's inherent value, but +1
PR is ready for review: https://github.com/django/django/pull/4106
On Tuesday, February 10, 2015 at 12:00:13 PM UTC-5, Carl Meyer wrote:
>
> On 02/10/2015 12:08 AM, Jannis Leidel wrote:
> >> On 10 Feb 2015, at 00:12, Tim Graham >
> wrote:
> >>
> >> Is it a best practice? In my unscientific sam
On 02/10/2015 12:08 AM, Jannis Leidel wrote:
>> On 10 Feb 2015, at 00:12, Tim Graham wrote:
>>
>> Is it a best practice? In my unscientific sampling, none of the
>> following ship tests inside the application directory, but rather
>> in a separate "tests" directory. Or did I misunderstand what yo
Pull request is here.
https://github.com/django/django/pull/4105
понедельник, 9 февраля 2015 г., 22:25:50 UTC+2 пользователь Josh Smeaton
написал:
>
> Hi Andriy,
>
> The direction looks OK to me, but it'll be a lot easier to review properly
> once you've opened a pull request.
>
> I'm not sure t
The trickiest tests to move will be the gis tests.
When gis is enabled, django/contrib/gis/tests is added to the discovery
path. This doesn't affect which tests are discovered per se--all gis tests
are discovered anyway by discovery on the parent app
django.contrib.gis--but it causes the later
Hi Aron,
With option 3, this would work:
class Cousin(models.Model):
child = models.ForeignKey(Child, allow_override=True)
but it would raise an error without `allow_override`.
I think my question really is: should we treat reverse relations as
first-class fields, or not? If we do, 1) wou