On 4/9/2009 7:39 PM, Ned Batchelder wrote:
> George, I'd love to hear about your changes to coverage.py.
Over the weekend I made my test coverage test runner into a third party
app. So you just have to install the app, add some settings, and run
``manage.py test_coverage [app1 app2 ...]``. The co
I recently checked out coverage.py in more depth, and it seems to have a
much more current effort behind it, so I'm comfortable using it for coverage
integration.
As for someone to work with on GSoC, I'm not saying it has to be anyone, the
more the better. I think the deciding factor is the mento
George Song wrote:
> On 4/7/2009 11:25 AM, Kevin Kubasik wrote:
>
>> I actually proposed this as part of my GSoC project. I think there is
>> enough interest that basic coverage support could be seen in core.
>>
>
> I agree and have had some quick emails with Jacob about this. I think
> the
On 4/7/2009 11:25 AM, Kevin Kubasik wrote:
> I actually proposed this as part of my GSoC project. I think there is
> enough interest that basic coverage support could be seen in core.
I agree and have had some quick emails with Jacob about this. I think
there's a way to make this a stand-alone pa
Absolutely! I actually proposed this as part of my GSoC project. I think
there is enough interest that basic coverage support could be seen in core.
My research turned up figleaf, which seemed like a better fit (but its an
external dependency, and I'm not sure of the django policy on this,
especial
I did a fair amount of work last week with ``coverage.py``. I came up
with a pretty flexible system which suited my own development needs
but is probably useful to a lot of people out there.
I noticed there's already a ticket open for this:
I've commented there as well. I was able to run ``runt
