Re: Django's doctest clashes with coverage.py
You're quite welcome. One other thing I forgot to mention: nosetest.py has a --with-coverage option, and Django support. I've used it to coverage test my Django code. --Ned. Marcin Kaszynski wrote: > > On Nov 25, 3:58 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > >> We recently added the >> ability for external projects to define new management commands >> specifically so that end-users could contribute features like this >> without the need to modify the Django core. >> > > I did not know that. Very cool. > > >> And, to pre-empt the follow on discussion - this policy of including >> other libraries is not up for debate. You may disagree, but we're not >> going to change it. >> > > Nope, after reading your explanation I think that is a good policy, > especially if there is a way to do such things via external add-ons. > > But we do have Ned's direct permission and the file does include > licensing information that basically means you can redistribute it in > source form as long as you don't remove the comments. So, we're back > to "think about the best way to handle the option", right? :) > > Ned: thanks for your work on the module, it is incredibly helpful > during testing. I spent the last two days adding tests and removing > unused code from my apps. > > -mk > > > > > -- Ned Batchelder, http://nedbatchelder.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django's doctest clashes with coverage.py
On Nov 25, 3:58 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > We recently added the > ability for external projects to define new management commands > specifically so that end-users could contribute features like this > without the need to modify the Django core. I did not know that. Very cool. > And, to pre-empt the follow on discussion - this policy of including > other libraries is not up for debate. You may disagree, but we're not > going to change it. Nope, after reading your explanation I think that is a good policy, especially if there is a way to do such things via external add-ons. But we do have Ned's direct permission and the file does include licensing information that basically means you can redistribute it in source form as long as you don't remove the comments. So, we're back to "think about the best way to handle the option", right? :) Ned: thanks for your work on the module, it is incredibly helpful during testing. I spent the last two days adding tests and removing unused code from my apps. -mk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django's doctest clashes with coverage.py
Please use coverage.py, I would be honored to have it included in Django core. If it's better as an add-on of some sort, that's great too. Let a thousand flowers bloom! --Ned. Todd O'Bryan wrote: > On Nov 24, 2007 9:58 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > >> If the licensing issue can't be resolved, it may be worth starting a >> standalone project to handle coverage tests. We recently added the >> ability for external projects to define new management commands >> specifically so that end-users could contribute features like this >> without the need to modify the Django core. >> > > I believe the author of coverage.py, Ned Batchelder, is on the list. > Has he said whether he's willing to have Django include it without > much hoop jumping? > > Todd > > > > > -- Ned Batchelder, http://nedbatchelder.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django's doctest clashes with coverage.py
On Nov 24, 2007 9:58 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > If the licensing issue can't be resolved, it may be worth starting a > standalone project to handle coverage tests. We recently added the > ability for external projects to define new management commands > specifically so that end-users could contribute features like this > without the need to modify the Django core. I believe the author of coverage.py, Ned Batchelder, is on the list. Has he said whether he's willing to have Django include it without much hoop jumping? Todd --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django's doctest clashes with coverage.py
I could be off base here but in regards to the the execution of
translation initialization I believe that is occurring because the
django.core.management.base attempts to switch the translation to
english if the can_import_settings attribute is set:
if self.can_import_settings:
from django.utils import translation
translation.activate('en-us')
According to the docs this is done because django-admin (manage.py)
executes some database stuff related to permissions. Since this is
set to True by the BaseCommand this is likely the cause.
You might try creating your own custom command that executes the test
runner but only after setting this attribute to false and checking
your results then.
Michael
blog.michaeltrier.com
On Nov 24, 2007 12:03 PM, Marcin Kaszynski <[EMAIL PROTECTED]> wrote:
>
> One more comment after a day of writing unit tests: installing
> coverage.py via a test runner is not a good idea.
>
> The test runner is executed pretty late and there is a chance that
> part of your code gets executed earlier. I do not know if this is the
> only possible case, but I had the code in appname/__init__.py files
> executed during translation initialization, which is way before Django
> even looks at the command line passed to manage.py.
>
> Right now my code detects the --with-coverage option and installs
> coverage right in projectname/manage.py as the very first thing,
> before importing any other module. This gives far more accurate
> results.
>
> I still believe it would be a good idea to add the --with-coverage
> option to Django, since it would make it a bit easier it for people to
> do proper testing (and one less excuse not to do it right). If it
> sounds good to you I can create a patch for that, moving the code that
> installs coverage.py to django.core.management.
>
> -mk
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Django's doctest clashes with coverage.py
On 11/24/07, Marcin Kaszynski <[EMAIL PROTECTED]> wrote: > > On Nov 24, 3:54 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > > As a side note, there is an existing ticket requesting that we add > > coverage support to Django's test system; any suggestions in this area > > are welcome. > > I really like the idea of having a --with-coverage option. As do I. > You closed the ticket because of licensing issues. Do we really have > to bundle coverage.py with Django to add that option? If it's going to be part of the core, then yes. If the licensing issue can't be resolved, it may be worth starting a standalone project to handle coverage tests. We recently added the ability for external projects to define new management commands specifically so that end-users could contribute features like this without the need to modify the Django core. > The test runner > might use coverage.py if available and complain otherwise. Besides, > bundling modules means additional recurring costs for you (as in "the > Django developers") and coverage.py is a module used only during > development; it might be a better idea to let users install it outside > of Django. This would be fundamentally inconsistent with the way that most of Django works. With the exception of database interfaces, Django includes all the batteries required for all of its core functions. We include SimpleJSON and a signal framework specifically to avoid the dependency problem. This has two advantages: - Stability: we update these libraries when there is a need to do so. We don't need to manage the differences between versions of libraries over which we have no control. - Simplicity: Everything works out of the box. We don't need to spend a lifetime debugging obscure errors that only occur on one particular packaged version of a library. And, to pre-empt the follow on discussion - this policy of including other libraries is not up for debate. You may disagree, but we're not going to change it. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django's doctest clashes with coverage.py
One more comment after a day of writing unit tests: installing coverage.py via a test runner is not a good idea. The test runner is executed pretty late and there is a chance that part of your code gets executed earlier. I do not know if this is the only possible case, but I had the code in appname/__init__.py files executed during translation initialization, which is way before Django even looks at the command line passed to manage.py. Right now my code detects the --with-coverage option and installs coverage right in projectname/manage.py as the very first thing, before importing any other module. This gives far more accurate results. I still believe it would be a good idea to add the --with-coverage option to Django, since it would make it a bit easier it for people to do proper testing (and one less excuse not to do it right). If it sounds good to you I can create a patch for that, moving the code that installs coverage.py to django.core.management. -mk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django's doctest clashes with coverage.py
On Nov 24, 3:54 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> > I tried to file this as a ticket, but trac kept rejecting it as spam
> Have you tried creating a login:
>
> http://code.djangoproject.com/settings
I did have the idea of creating one, but simply could not find the
page -- I poked around the wiki, looked through the patch guidelines,
tried to 'login' and finally decided that apparently trac accounts are
not for the mere mortals :)
Now I see that there _is_ a place that contains a link to a page that
lets you create an account, but I did not notice it because it is in a
section that looked like not interesting to me at that time ("Claiming
tickets").
> Generally, this will convince the spam checker to let you post tickets.
It worked, thanks. Ticket #6024.
> As a side note, there is an existing ticket requesting that we add
> coverage support to Django's test system; any suggestions in this area
> are welcome.
I really like the idea of having a --with-coverage option.
You closed the ticket because of licensing issues. Do we really have
to bundle coverage.py with Django to add that option? The test runner
might use coverage.py if available and complain otherwise. Besides,
bundling modules means additional recurring costs for you (as in "the
Django developers") and coverage.py is a module used only during
development; it might be a better idea to let users install it outside
of Django.
-mk
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Django's doctest clashes with coverage.py
On 11/23/07, Marcin Kaszynski <[EMAIL PROTECTED]> wrote: > > Hi, > > I tried to file this as a ticket, but trac kept rejecting it as spam > even after I removed all the links and changed contents. I'm posting > it here because others might find it useful too. Have you tried creating a login: http://code.djangoproject.com/settings Generally, this will convince the spam checker to let you post tickets. > When you use coverage.py in "manage.py test" it incorrectly reports > some statements as not executed. This is a known issue with > coverage.py. From http://nedbatchelder.com/code/modules/coverage.html > : > > "Older versions of doctest interfere with coverage's tracing of > statements, and you may get reports that none of your code is > executing. Use this patch[1] to doctest.py if you are experiencing > problems." This needs to be opened as a ticket so that it isn't forgotten. If you create a login and still can't submit a ticket, let me know and I'll create a ticket for you. As a side note, there is an existing ticket requesting that we add coverage support to Django's test system; any suggestions in this area are welcome. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
