optional doctests

[John Cremona]

1. In the Developers' Guide
http://www.sagemath.org/doc/developer/conventions.html regarding
optional doctests it says

"Mark a doctest as optional if it requires optional packages; even
better, mark it as optional - PKG_NAME if it requires the package
PKG_NAME."

I think this is not strong enough, and should be changed to

"If a doctest requires the package PKG_NAME to run, mark it as
optional using "optional - PKG_NAME". THE PKG_NAME should be the
basename for the optional package, not the full name which includes a
release date."

The main point here is to make it compusory to have the spkg name as
well as the tag "optional". Do you agree? If so, the Guide needs
editing.

2. I would find it useful to have a flag which does the reverse of
"optional", say "not-if-optional" to tag a doctest which gets run if
the optional spkg is not installed but not if it is. In case this
seems odd, the optional spkg I have in mind is
database_cremona_ellcurve which consists entirely of data, not code,
and we are always running into situations where tests behave
differently depending on whether or not the optional databse is
installed. It would be good to have both. In my own testing I keep
on having to uninstall the optional database, which is tedious as it
is automatic (though it only involves deleting two files in this
case).

Does anyone else think this would a useful additional feature?

John

[Dima Pasechnik]

You can perhaps emulate this using --only-optional= 

when testing. Although this looks like a workaround...

I also wonder what to do if more than one optional package is needed for a particular test to work.

 

Dima

John

[Robert Bradshaw]

On Mon, Oct 15, 2012 at 4:22 AM, John Cremona <john.c...@gmail.com> wrote:
> 1. In the Developers' Guide
> http://www.sagemath.org/doc/developer/conventions.html regarding
> optional doctests it says
>
> "Mark a doctest as optional if it requires optional packages; even
> better, mark it as optional - PKG_NAME if it requires the package
> PKG_NAME."
>
> I think this is not strong enough, and should be changed to
>
> "If a doctest requires the package PKG_NAME to run, mark it as
> optional using "optional - PKG_NAME". THE PKG_NAME should be the
> basename for the optional package, not the full name which includes a
> release date."
>
> The main point here is to make it compusory to have the spkg name as
> well as the tag "optional". Do you agree? If so, the Guide needs
> editing.

Makes sense to me. Perhaps one could even require "optional package
FOO" which would make detecting them automatically
(http://trac.sagemath.org/sage_trac/ticket/13540) even easier for
these optional tests.

> 2. I would find it useful to have a flag which does the reverse of
> "optional", say "not-if-optional" to tag a doctest which gets run if
> the optional spkg is not installed but not if it is. In case this
> seems odd, the optional spkg I have in mind is
> database_cremona_ellcurve which consists entirely of data, not code,
> and we are always running into situations where tests behave
> differently depending on whether or not the optional databse is
> installed. It would be good to have both. In my own testing I keep
> on having to uninstall the optional database, which is tedious as it
> is automatic (though it only involves deleting two files in this
> case).
>
> Does anyone else think this would a useful additional feature?

Perhaps "optional not XXX" could be a useful construct for any XXX.
However, I think the tests might be worth re-writing if they fail due
to additional data. (Changing == into >= may be perfectly fine
depending on what we are actually trying to verify; who cares that
there are *only* a given number of curves in the base Sage install?)

- Robert

[John Cremona]

Thanks, Robert -- I think you are the author of the doctest (line 6454
in heegner.py) which currently fails when the optional large elliptic
curve database is installed! ("Fails" in the sense that something
does work whil the doctest is written with the assumtption that it
will not). Is it possible that you can change that example to an
equivalent one with a curve of conductor much greater then 300000?

> - Robert
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To post to this group, send email to sage-...@googlegroups.com.
> To unsubscribe from this group, send email to sage-devel+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>
>

[Robert Bradshaw]

How about that...

> ("Fails" in the sense that something
> does work whil the doctest is written with the assumtption that it
> will not). Is it possible that you can change that example to an
> equivalent one with a curve of conductor much greater then 300000?

Yep, that certainly makes sense.

[John Cremona]

> How about that...
>
>> ("Fails" in the sense that something
>> does work whil the doctest is written with the assumtption that it
>> will not). Is it possible that you can change that example to an
>> equivalent one with a curve of conductor much greater then 300000?

PS: http://www.lmfdb.org/EllipticCurve/Q