Re: runserver fails on non-fatal model validation errors

2013-05-09 Thread Brendan Jurd 
On Sunday, 5 May 2013 01:23:51 UTC+10, Shai Berger wrote:

>
> I've been going through what I've missed on the list, and found this 
> 2-month- 
> old message that seems to have gone unanswered. I'm sorry for being so 
> late to 
> the party, but... 
>

Thanks all the same for your reply -- better late than never. 


Why? If you know it's not really a problem, why don't you want it silenced? 
> I understand that (as you mention on the ticket) you don't want to turn 
> off 
> model validation -- I imagine there are plenty of other models to 
> validate. 
> But why would you want to keep a false warning?
>

Well it's entirely possible that I might genuinely make that mistake 
(mentioning a non-existent field in 'ordering') somewhere in my app, and 
I'd like model validation to pick me up on that if it happens.  So I 
wouldn't want to shut that category of error up altogether.  If there were 
a reasonable way to make the model validation more discerning about this 
(look up the fields produced by the model's 'objects' manager, rather than 
just the fields defined on the model), that would be great, but I'm getting 
the impression that it wouldn't be worth pursuing for a weird corner case 
such as this.

1) Define a custom field type, with the string representation (and, if you 
> like, 
> python value) as the string of dot-separated integers, but with the db 
> value 
> as the array. This may require other changes in your code, but I suspect 
> it is 
> the more accurate database representation, so may also get you some 
> benefits. 
>

A reasonable suggestion, but I do have other reasons for wanting the db 
value to be the text form.
 

>
> 2) Since you're overriding the manager's get_query_set() anyway, Instead 
> of 
> using the "ordering" meta option, just add the "order_by" clause to the 
> customized queryset. Admittedly, this is more of a workaround than a 
> solution. 
>

I tried this, and can confirm that it gets me the result I'm looking for 
with no validation errors.  To be honest I don't know why I didn't think of 
it myself, but thank you for pointing it out.


> I'd be mildly supportive of a "pragma" -- say, an extra option in the Meta 
> class --  that tells validation to ignore some checks (or even the model 
> in 
> general). Something like: 
>
> class YourModel(models.Model): 
>a = ... 
> ... 
> class Meta: 
>ordering = ['b'] 
>validation_ignore = ['ordering_fields_exist']  # Select 
> validations 
> or 
>validation_ignore = True  # Just skip this model 
>
> That is, I'd be supportive of it API-wise; I'm not sure the use-case 
> justifies 
> the cost of the feature. 
>

Yeah, does seem like overkill.  If there were widespread reports of 
problematic model validation errors, then it would make more sense, but 
mine is the only such report I've noticed.
 

>
> Another proper solution, IMO, is adding support for database-level 
> calculated 
> fields (which would allow you to define your calculated field on the 
> model, 
> avoiding the problems altogether). But this is not a simple thing, as each 
> database engine has its own expression language. Perhaps fields allowing 
> explicit SQL in their definition would work (in the sense that you'd be 
> able to 
> use them on one database backend, at least). But that idea is completely 
> halfbaked. 
>

That sounds quite nice, actually.  If such a feature were available I'd 
definitely make use of it.

You're right that it wouldn't be portable across database backends, but 
then neither is my current solution using a customised queryset with 
'extra'.

Cheers,
BJ

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Setting aside easy-pickings for sprints

2013-05-09 Thread Russell Keith-Magee 
On Thu, May 9, 2013 at 11:43 PM, Daniele Procida  wrote:

> On Mon, Apr 29, 2013, Daniele Procida  wrote:
>
> >At the start of the sprints at DjangoCon Europe next month, I'll be
> >holding a workshop called "Don't be afraid to commit" for people who'd
> >like to get involved in Django projects (including Django itself of
> course).
>
> I've written up the tutorial for the workshop:
>
> 
>
> I'd appreciate any comments/corrections/criticism.
>
> >Between now and then would it be possible for some very simple
> >tickets to be set aside for people who will then have a chance to
> >tackle some real issues at their first sprint, after the workshop?
>
> I haven't yet been through the tickets looking for suitable candidates,
>  but I will do that over the next week.
>
> Assuming that people come out of this workshop and feel ready to take part
> in the Django sprint, they will likely be first-time Django committers.
> Would anyone like to volunteer to help steer them into the process?


I'll be at the sprints, and providing guidance for first-timers is always
one of my high priorities. I won't be able to dedicate myself solely to
helping newcomers, but I'll definitely be helping out on this front.

Russ %-)

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: test discovery

2013-05-09 Thread Russell Keith-Magee 
On Thu, May 9, 2013 at 11:30 PM, Carl Meyer  wrote:

> Hi Russ,
>
> On 05/09/2013 04:51 AM, Russell Keith-Magee wrote:
> > Great work Carl and Preston! (And everyone else who had a hand in the
> > patch - I know this has been kicking around for a while now)
>
> Thanks for the reminder; I should have mentioned that Mahdi Yusuf did
> the initial draft patch, based on Jannis' django-discover-runner, which
> was based on code I showed on a slide in my "Django and Testing" talk at
> PyCon 2012; it all comes full circle :-)
>
> > I agree with Jacob's tests aren't production sensitive, so making a fast
> > transition to the new test discovery has less impact.
> >
> > However, we know from experience that it doesn't matter how much we flag
> > this change in the release notes, they won't be read, and *someone* is
> > going to get stung. In an ideal world, it would be good to be able to
> > warn people who upgrade that their test suite may not be run as expected.
> >
> > We've had a proposal kicking around for a while to add a management
> > command that does an "upgrade check". I'm wondering if this might be an
> > opportune time to dig into this some more.
> >
> > To be clear, this isn't something I consider to be a merge blocker. I'd
> > be happy to see 1.6 released with a fast transition to the new test
> > runner. It would just be nice icing on the cake if we can get an upgrade
> > validator included in the same release.
>
> It wouldn't be too hard to write something that tried test discovery
> using the old runner and using the new runner and did a simple
> comparison of test counts to warn you if they differ.
>
> I'm not personally likely to work on this "upgrade checks" framework,
> but if it does happen I'd be happy to contribute this check to it.


I thought about that approach, but my immediate reaction was that it will
end up producing more false positives than helpful feedback. Even the
simple case -- myapp.TestCase -> myapp.tests.TestCase -- is going to
require some name munging to work out if the old test and the new test are
actually the same one. Since this is for a short-lived transitional tool,
the effort involved in getting it right exceeds the value gained by having
it, IMHO.

I'd prefer something much simpler:

 * On syncdb/validate, check for a marker somewhere in user space.

 * If the marker isn't present, do a check for likely problems. In this
case, look for the value of TEST_RUNNER; if it's set to the new default
value, display a warning about the change in test discovery format. Add
similar checks for other setting changes, or warnings about features that
have been fully deprecated (e.g., the final transition of the {% url %}
behavior)

 * Provide a management command to set marker.

 * On the next syncdb/validate, the marker is present, so the install is
verified as being "updated", and no warnings are displayed.

This leaves the question of where to put the marker. Some initial ideas:

 - a file on disk (e.g., an .updated file next to the settings file)
 - a new setting (VERIFIED_VERSION = "1.5")
 - a key-value table in a database used only for Django administrivia

Essentially, this would give us a place to put the "NO REALLY, READ THIS"
warnings that we need in release notes, and make those messages slightly
targeted.

Yours,
Russ Magee %-)

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Recommending a Python 3-compatible MySQL connector

2013-05-09 Thread Travis Jensen 

Thanks, Aymeric. I grabbed the latest Django code and things worked like a 
charm.

Now, I have a decision to make: Stay on the Django/Python 3 bleeding edge 
or back off to Python 2.7.  My project's timeline says I won't release 
until after Django 1.6 (even with some slop for slipping releases), but it 
still feels dicey. On the other hand, on a brand new project, I'd prefer to 
be looking at Python's future rather than sticking in its past. :)

tj

On Wednesday, May 8, 2013 5:26:41 AM UTC-6, Aymeric Augustin wrote:
>
> On 7 mai 2013, at 08:34, Aymeric Augustin 
>  
> wrote:
>
> These problems look fairly easy. I plan to work on them.
>
>
> I just updated the pull request and everything works except BinaryField:
> https://code.djangoproject.com/ticket/20025#comment:5
>
> Something forces the output to be a string, either in the MySQL connector 
> or in the converters registered by Django.
>
> I would appreciate some help on this.
>
> Here's how to setup the MySQL connector with python 3.3:
>
> $ pyvenv-3.3 mysql-py33
> $ . mysql-py33/bin/activate
> $ curl http://python-distribute.org/distribute_setup.py | python
> $ git clone https://github.com/clelland/MySQL-for-Python-3
> $ cd MySQL-for-Python-3
> $ python setup.py install
>
> Then run model_fields tests.
>
> -- 
> Aymeric.
>
>
>  
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Help with #20378 - Reverse join fails when GenericRelation is defined on an abstract model

2013-05-09 Thread Gavin Wahl 
I'd like to have a go at fixing this bug, but I'm not sure where to start. 
The problem seems to be that there's only a single instance of the field 
per model, so field.model is always the abstract class. I can't see a way 
to access the concrete class from the field instance. If the field only has 
a reference to the abstract model, which doesn't have a pk, how can it 
calculate join columns for the concrete model?

https://code.djangoproject.com/ticket/20378

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Setting aside easy-pickings for sprints

2013-05-09 Thread Daniele Procida 
On Mon, Apr 29, 2013, Daniele Procida  wrote:

>At the start of the sprints at DjangoCon Europe next month, I'll be
>holding a workshop called "Don't be afraid to commit" for people who'd
>like to get involved in Django projects (including Django itself of course).

I've written up the tutorial for the workshop:



I'd appreciate any comments/corrections/criticism.

>Between now and then would it be possible for some very simple
>tickets to be set aside for people who will then have a chance to
>tackle some real issues at their first sprint, after the workshop?

I haven't yet been through the tickets looking for suitable candidates,  but I 
will do that over the next week.

Assuming that people come out of this workshop and feel ready to take part in 
the Django sprint, they will likely be first-time Django committers. Would 
anyone like to volunteer to help steer them into the process?

Thanks,

Daniele

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: test discovery

2013-05-09 Thread Carl Meyer 
On 05/09/2013 07:50 AM, Andrew Godwin wrote:
> Just want to say that I'm happy with a "fast transition".
> 
> Is there a possibility we can detect the case where the tests might be
> broken (how might they be?) and print a helpful error message?

Two kinds of potential breakage:

- The most common will be missing tests; doctests, or tests in files
that don't match the test*.py pattern, which are currently run because
they are in models.py or manually imported into a tests/__init__.py,
won't be discovered by the new runner. Some people may also consider it
a "breakage" that tests in their pip-installed external apps are no
longer run by default.

- Less common will be tests that are in the codebase for some reason
(vendored third-party code, for instance?) that weren't found or run by
the previous runner, but are found and run (and perhaps fail) with the
new runner.

The first kind of breakage I don't think we can reasonably discover at
runtime; it would mean trying both discovery methods on every single
test run and comparing test counts. We could do this in a special
"upgrade check" like Russ suggested, but not every time you run tests.

The second issue I'm not too concerned about. If the
previously-undiscovered tests pass, then there's not really a problem.
If they fail, it shouldn't be too hard to figure out what's going on.

Carl

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: test discovery

2013-05-09 Thread Carl Meyer 
Hi Russ,

On 05/09/2013 04:51 AM, Russell Keith-Magee wrote:
> Great work Carl and Preston! (And everyone else who had a hand in the
> patch - I know this has been kicking around for a while now)

Thanks for the reminder; I should have mentioned that Mahdi Yusuf did
the initial draft patch, based on Jannis' django-discover-runner, which
was based on code I showed on a slide in my "Django and Testing" talk at
PyCon 2012; it all comes full circle :-)

> I agree with Jacob's tests aren't production sensitive, so making a fast
> transition to the new test discovery has less impact.
> 
> However, we know from experience that it doesn't matter how much we flag
> this change in the release notes, they won't be read, and *someone* is
> going to get stung. In an ideal world, it would be good to be able to
> warn people who upgrade that their test suite may not be run as expected.
> 
> We've had a proposal kicking around for a while to add a management
> command that does an "upgrade check". I'm wondering if this might be an
> opportune time to dig into this some more.
> 
> To be clear, this isn't something I consider to be a merge blocker. I'd
> be happy to see 1.6 released with a fast transition to the new test
> runner. It would just be nice icing on the cake if we can get an upgrade
> validator included in the same release.

It wouldn't be too hard to write something that tried test discovery
using the old runner and using the new runner and did a simple
comparison of test counts to warn you if they differ.

I'm not personally likely to work on this "upgrade checks" framework,
but if it does happen I'd be happy to contribute this check to it.

Carl

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: test discovery

2013-05-09 Thread Carl Meyer 
Hi Tom,

On 05/09/2013 03:27 AM, Tom Christie wrote:
> * Will it be possible to globally configure the default file/path pattern?
>   Jannis's django-discover-runner includes support for a
> `TEST_DISCOVER_PATTERN` - is there anything similar, or just the command
> line `--patterns` option?  The use case I'm looking for is a single
> `tests` directory containing all the test modules, and I'm wondering if
> that'd be easy to support?

One of the goals here was to avoid adding more settings, so there isn't
a way to configure the pattern globally at this point. That may be
something we want to revisit, though; if you do need a different
pattern, you'll need it every time you run your tests, which basically
means you're either wrapping up "manage.py test" in a shell script or
overriding the test command with your own tweaked version. If we can
avoid the need for that by adding a setting, it might be worth it.

Your use case is very easy to support if you don't mind naming your test
files inside the tests/ directory all test_something.py. If you don't
like that, then you might need to use something like --pattern "*.py".

> * Is this work broadly compatible with `django-discover-runner`?  I'd
> really like to make use of it in third party packages, but I'm wondering
> if I'd be able to do so in a way that lets me also
> provide compatibility with older versions of Django.

I think the capabilities of the command-line interface in this patch are
a superset of the capabilities of discover-runner. It's smarter about
figuring some pythonpath things out, and better about handling multiple
test labels, but anything that works with discover-runner should work
here too.

If necessary it wouldn't be at all hard to backport this code into
discover-runner so they are exactly the same; I haven't discussed this
with Jannis yet.

Carl

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: test discovery

2013-05-09 Thread Andrew Godwin 
Just want to say that I'm happy with a "fast transition".

Is there a possibility we can detect the case where the tests might be
broken (how might they be?) and print a helpful error message?

Andrew


On Thu, May 9, 2013 at 11:51 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Thu, May 9, 2013 at 5:00 AM, Carl Meyer  wrote:
>
>> Hi all,
>>
>> Preston Timmons and I have been working the last several weeks to get
>> the test discovery branch (#17365) ready for merge, and I think we now
>> have a pull request ready for consideration:
>> https://github.com/django/django/pull/1050
>>
>> Brief summary of the features, changes, and open questions:
>>
>> * You can now place tests in any file matching the pattern 'test*.py',
>> anywhere in your codebase, rather than only in tests.py and models.py
>> modules of an INSTALLED_APP. The filename pattern is customizable via
>> the --pattern argument to "manage.py test".
>>
>> * When you run "manage.py test" with no arguments, tests are discovered
>> and run in all subdirectories (recursively) of the current working
>> directory. (This means that django.contrib and other third-party app
>> tests are no longer run by default).
>>
>> * When you pass arguments to "manage.py test", they are now full Python
>> dotted module paths. So if you have a "myproject.myapp" app, and its
>> tests.py contains "SomeTestCase", you would now run that single test
>> case via "manage.py myproject.myapp.tests.SomeTestCase" rather than
>> "manage.py myapp.SomeTestCase". This is longer, but allows more control
>> when an app's tests are split into multiple files, and allows for tests
>> to be placed anywhere you like.
>>
>> * Doctests are no longer discovered by default; you will need to
>> explicitly integrate them with your test suite as recommended in the
>> Python docs: http://docs.python.org/2/library/doctest.html#unittest-api
>>
>> * Tests in models.py and tests/__init__.py will no longer be discovered
>> (as those don't match the default filename pattern).
>>
>> * The old test runner, and Django's extensions to the doctest module,
>> are deprecated and will be removed in Django 1.8; they could of course
>> be packaged separately if some people would like to continue using them.
>>
>>
> Great work Carl and Preston! (And everyone else who had a hand in the
> patch - I know this has been kicking around for a while now)
>
>
>> Open question: how to handle the transition?
>>
>> Jacob has suggested that back-compat breaks in test-running are not as
>> serious as in production code, and that we should just switch to the new
>> test runner by default in Django 1.6. This is what the pull request
>> currently does. This will mean that some people's test suites will
>> likely be broken when they upgrade to 1.6. They would have two options,
>> both documented in the release notes: they can update their test suite
>> to be discovery-compatible immediately, or they can just set TEST_RUNNER
>> to point to the old runner and get back the old behavior, which they can
>> keep using until Django 1.8 (or longer, if they package the old runner
>> externally).
>>
>> The alternative would be to keep the old test runner as the default in
>> global_settings.py until it is removed in 1.8, and add the new runner as
>> the TEST_RUNNER in the startproject-generated settings.py. This would
>> provide a gentler transition for upgrading projects. On the other hand,
>> we just recently got the startproject settings.py all cleaned-up,
>> slimmed-down, and newbie-friendly, so it would make me sad to start
>> polluting it again with stuff that new projects generally shouldn't care
>> about, for solely legacy reasons.
>>
>
> I agree with Jacob's tests aren't production sensitive, so making a fast
> transition to the new test discovery has less impact.
>
> However, we know from experience that it doesn't matter how much we flag
> this change in the release notes, they won't be read, and *someone* is
> going to get stung. In an ideal world, it would be good to be able to warn
> people who upgrade that their test suite may not be run as expected.
>
> We've had a proposal kicking around for a while to add a management
> command that does an "upgrade check". I'm wondering if this might be an
> opportune time to dig into this some more.
>
> To be clear, this isn't something I consider to be a merge blocker. I'd be
> happy to see 1.6 released with a fast transition to the new test runner. It
> would just be nice icing on the cake if we can get an upgrade validator
> included in the same release.
>
> Yours,
> Russ Magee %-)
>
>  --
> 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

Re: test discovery

2013-05-09 Thread Russell Keith-Magee 
On Thu, May 9, 2013 at 5:00 AM, Carl Meyer  wrote:

> Hi all,
>
> Preston Timmons and I have been working the last several weeks to get
> the test discovery branch (#17365) ready for merge, and I think we now
> have a pull request ready for consideration:
> https://github.com/django/django/pull/1050
>
> Brief summary of the features, changes, and open questions:
>
> * You can now place tests in any file matching the pattern 'test*.py',
> anywhere in your codebase, rather than only in tests.py and models.py
> modules of an INSTALLED_APP. The filename pattern is customizable via
> the --pattern argument to "manage.py test".
>
> * When you run "manage.py test" with no arguments, tests are discovered
> and run in all subdirectories (recursively) of the current working
> directory. (This means that django.contrib and other third-party app
> tests are no longer run by default).
>
> * When you pass arguments to "manage.py test", they are now full Python
> dotted module paths. So if you have a "myproject.myapp" app, and its
> tests.py contains "SomeTestCase", you would now run that single test
> case via "manage.py myproject.myapp.tests.SomeTestCase" rather than
> "manage.py myapp.SomeTestCase". This is longer, but allows more control
> when an app's tests are split into multiple files, and allows for tests
> to be placed anywhere you like.
>
> * Doctests are no longer discovered by default; you will need to
> explicitly integrate them with your test suite as recommended in the
> Python docs: http://docs.python.org/2/library/doctest.html#unittest-api
>
> * Tests in models.py and tests/__init__.py will no longer be discovered
> (as those don't match the default filename pattern).
>
> * The old test runner, and Django's extensions to the doctest module,
> are deprecated and will be removed in Django 1.8; they could of course
> be packaged separately if some people would like to continue using them.
>
>
Great work Carl and Preston! (And everyone else who had a hand in the patch
- I know this has been kicking around for a while now)


> Open question: how to handle the transition?
>
> Jacob has suggested that back-compat breaks in test-running are not as
> serious as in production code, and that we should just switch to the new
> test runner by default in Django 1.6. This is what the pull request
> currently does. This will mean that some people's test suites will
> likely be broken when they upgrade to 1.6. They would have two options,
> both documented in the release notes: they can update their test suite
> to be discovery-compatible immediately, or they can just set TEST_RUNNER
> to point to the old runner and get back the old behavior, which they can
> keep using until Django 1.8 (or longer, if they package the old runner
> externally).
>
> The alternative would be to keep the old test runner as the default in
> global_settings.py until it is removed in 1.8, and add the new runner as
> the TEST_RUNNER in the startproject-generated settings.py. This would
> provide a gentler transition for upgrading projects. On the other hand,
> we just recently got the startproject settings.py all cleaned-up,
> slimmed-down, and newbie-friendly, so it would make me sad to start
> polluting it again with stuff that new projects generally shouldn't care
> about, for solely legacy reasons.
>

I agree with Jacob's tests aren't production sensitive, so making a fast
transition to the new test discovery has less impact.

However, we know from experience that it doesn't matter how much we flag
this change in the release notes, they won't be read, and *someone* is
going to get stung. In an ideal world, it would be good to be able to warn
people who upgrade that their test suite may not be run as expected.

We've had a proposal kicking around for a while to add a management command
that does an "upgrade check". I'm wondering if this might be an opportune
time to dig into this some more.

To be clear, this isn't something I consider to be a merge blocker. I'd be
happy to see 1.6 released with a fast transition to the new test runner. It
would just be nice icing on the cake if we can get an upgrade validator
included in the same release.

Yours,
Russ Magee %-)

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: test discovery

2013-05-09 Thread Tom Christie 
Hi Carl,

  Excellent, excellent stuff - many thanks to both yourself and Preston.

Couple of questions:

* Will it be possible to globally configure the default file/path pattern?
  Jannis's django-discover-runner includes support for a 
`TEST_DISCOVER_PATTERN` - is there anything similar, or just the command 
line `--patterns` option?  The use case I'm looking for is a single `tests` 
directory containing all the test modules, and I'm wondering if that'd be 
easy to support?
* Is this work broadly compatible with `django-discover-runner`?  I'd 
really like to make use of it in third party packages, but I'm wondering if 
I'd be able to do so in a way that lets me also provide compatibility with 
older versions of Django.

Thanks again,

  Tom

On Wednesday, 8 May 2013 23:04:29 UTC+1, Carl Meyer wrote:
>
> Hi Anssi, 
>
> On 05/08/2013 03:31 PM, Anssi K��ri�inen wrote: 
> > It would be really nice to be able to use same syntax for running a 
> > single Django's testcase at least for a while. I expect that there 
> > will be problems if inspecting how a given test case behaves in older 
> > versions compared to HEAD. Also, bisecting over the test case renaming 
> > boundary will be really ugly. I don't believe end users will have too 
> > much problems with this, but bug hunting and development in Django 
> > itself will be a bit more tedious to do. 
>
> I don't think this is enough of a problem to warrant more code to try to 
> work around it. 
>
> If you're bisecting, at worst this means having two commands in your 
> shell history instead of one and hopping up to the right one for each 
> bisect step. I think this is a minor irritation that will fade away soon 
> enough. 
>
> Most of our test apps are small/fast enough that you could just run the 
> whole app when bisecting instead of an individual TestCase, making this 
> a non-issue (since Django's test apps are top-level on sys.path, the 
> command to run a single app in Django's test suite is the same with the 
> new runner as with the old: "python runtests.py app_name"). 
>
> Carl 
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.