Could you elaborate more on spkg-check?

[Simon King]

Dear sage devel,

currently I am writing a test suite for my cohomology spkg. In the
Developer's Guide, I read:

spkg-check: this file runs the test suite. This is somewhat optional
since not all spkgs have test suites. If possible do create such a
script since it helps isolate bugs in upstream packages

OK, I have spkg-check. But what exactly is it supposed to do? Is it
fine to print on the screen whether all tests passed or not, and in
the latter case to save the log in some file test.log in the current
directory?

And when will spkg-check be called? Is this something that the user
has to do manually? Will there be tests on a regular basis?

Perhaps these informations could go into the Developer's Guide as
well.

Best regards,
Simon

[gsw]

Hi Simon,

first of all, "sage-check" is something specific to Sage. The Sage
project is expanding the number of platforms Sage runs on (think of
Solaris, and "native Windows"), new compiler versions (GCC 4.4),
eventually switching to new versions of NTL, GMP/MPIR, and so on.
This means that although the author of a certain spkg might not have
had a specific setting in mind, or the latter just wasn't exisiting at
creation time of the spkg, the Sage project might want to compile/use
this spkg in an environment it has never been tested/run in before.

Likely, there are problems (see other threads regarding Singular/GCC
4.4, or Solaris, or BSD, ...).

The "sage-check" script should be a device to determine quickly "YES,
sir, we do have some problem in this new setting!", and provide, if
possible, a starting point for debugging/solving this problem.

So if your spkg is, say, pure Python/Cython, probably all may be done
by doctests.

But if you have, say, a C or CPP library in your spkg, it is a must
that the spkg-check is executable without Sage/Python/Cython running
at all, to be able to detect linker problems, compiler issues,
platform dependencies, and the like.

So the spkg-check scripts in general are not at all called by the
users. But they are very helpful for integrators, should any problems
arise. So the output should be reproducible, and a kind of "test.log"
is always a good idea.

If this does answer your questions, please feel free to open a trac
ticket "Developers' Guide enhancement: About spkg-check". :-)

Cheers,
gsw

[Minh Nguyen]

On Mon, Jul 6, 2009 at 6:13 AM, gsw<Georg...@googlemail.com> wrote:
>

<SNIP>

> If this does answer your questions, please feel free to open a trac
> ticket "Developers' Guide enhancement: About spkg-check". :-)

If a trac ticket is opened about this, then I think one also needs to
add information about timed out errors, as discussed at

http://groups.google.com/group/sage-devel/browse_thread/thread/be04934d5190dcbc

--
Regards
Minh Van Nguyen

[Simon King]

Hi Georg,

On 5 Jul., 22:13, gsw <GeorgSWe...@googlemail.com> wrote:
> first of all, "sage-check" is something specific to Sage.

Do you mean spkg-check? But sure, this is Sage specific as well, since
AFAIK spkg stands for Sage package.

> But if you have, say, a C or CPP library in your spkg, it is a must
> that the spkg-check is executable without Sage/Python/Cython running
> at all, to be able to detect linker problems, compiler issues,
> platform dependencies, and the like.

My package does involve C libraries, and also involves some
executables. However, the main part is Cython.

But apparently I completely misunderstood the role of spkg-check. My
approach was to build some extensions for Sage (if it fails in this
early stage: Bad luck...!), and then to test *the extensions* rather
than to test the build process.

Hence, I thought that spkg-check is a sage-script that takes care of
tests (e.g. doc-tests) covering all extensions. Note that this is non-
trivial, since it is currently not really possible to test a pyx-file
nor a __init__.py with "sage -t"; see
http://groups.google.com/group/sage-support/browse_thread/thread/534306c87e7fac7a/e2435ee9b13e972d

:-/

I wonder what I can do in this case.

I have a script that walks through all public methods of classes that
are defined in modules of the package. It also complains if it finds a
method without doc test. Certainly useful, as it can be applied to any
extension module. But currently, I can't offer more than that.

My package involves a modified part of the C-MeatAxe library. It has a
test suite, but I never really used it. Perhaps I should try to add
this to my spkg-check.

The package also involves not-yet-published C-libraries and
executables written by David Green. They don't have a test suite. Of
course, the doc tests would fail if something is wrong with the C-
library, but I understand that it wouldn't help to locate problems
with portability etc.

> If this does answer your questions, please feel free to open a trac
> ticket "Developers' Guide enhancement: About spkg-check". :-)

I think I will open such ticket in a few days. I need to think a few
things over. My hope was to get my package ready for publication this
week end, but there was too much trouble with the doc tests alone.

Cheers,
Simon

[gsw]

On 5 Jul., 23:06, Simon King <simon.k...@uni-jena.de> wrote:
> Hi Georg,
>
> On 5 Jul., 22:13, gsw <GeorgSWe...@googlemail.com> wrote:
>
> > first of all, "sage-check" is something specific to Sage.
>
> Do you mean spkg-check? But sure, this is Sage specific as well, since
> AFAIK spkg stands for Sage package.

Ah, typo on my side. It is "spkg-check" we are talking about, of
course! I don't know if a "sage-check" script even exists.

Sorry,
gsw

>
> > But if you have, say, a C or CPP library in your spkg, it is a must
> > that the spkg-check is executable without Sage/Python/Cython running
> > at all, to be able to detect linker problems, compiler issues,
> > platform dependencies, and the like.
>
> My package does involve C libraries, and also involves some
> executables. However, the main part is Cython.
>
> But apparently I completely misunderstood the role of spkg-check. My
> approach was to build some extensions for Sage (if it fails in this
> early stage: Bad luck...!), and then to test *the extensions* rather
> than to test the build process.
>
> Hence, I thought  that spkg-check is a sage-script that takes care of
> tests (e.g. doc-tests) covering all extensions. Note that this is non-
> trivial, since it is currently not really possible to test a pyx-file

> nor a __init__.py with "sage -t"; seehttp://groups.google.com/group/sage-support/browse_thread/thread/5343...

[William Stein]

The 100% entire point of spkg-check is to run the line

make check # or equivalent

that many spkg's upstream scripts provide, analyze the results and
exit with a 0 error code if and only if the test suite passes. The
point was that we wanted to put running the upstream test suite in
spkg-check instead of spkg-install (which we were doing), since the
test suite often takes a long time to run and it is nice to easily
make it is possible to not run it.

I think that this thread contains a lot of other discussion about what
people think spkg-check is meant for. I think it's the above, since I
made it up in the first place for that reason only.

Note that spkg-check has remained almost entirely unused in Sage. It
is only used if you do

export SAGE_CHECK=yes

in which all spkg-check files are run, and if any exit with a code
other than 0 then the build process stops with an error.

-- William