[albatross-users] Re: Build failure with python 2.3: test failure

[Fabian Fagerholm]

First, apologies for the delay; at the moment, this is my average
response time. I hope to reduce it in the future without the sacrifice
of sleep.

On Fri, 2003-11-07 at 02:04, Dave Cole wrote:
> All of those failures are in a class of tests that would be quite ugly
> and difficult to fix.

Not neccessarily: I have a fix now that was not difficult to implement,
and given a little more time, I could reduce its ugliness to an
acceptable level. Given even more time, I could actually make it quite
nice to look at.

> The only way I can see that we can fix these would require that we
> either respectively redefine True and False to 1 and 0, or postprocess
> the results of the test (very flakey).

I have taken another approach: preprocessing template test fragments
into real test fragments according to build-time python version
detection. I will elaborate below.

> Hmm...  Maybe your suggestion would work.  Maybe we could create some of
> the doctest files as part of the build process.  This would mean that
> all pickle and repr strings would match the version of Python being used
> to install Albatross.

I think you are absolutely right in stating that the build process is
the place to do this. My solution works as follows:

      * The test fragment files are renamed to have a suffix of .in,
        becoming templates for the real files, and the critical parts
        are modified as follows:
              * The textual representations for true and false are
                converted to __xTRUEx__ and __xFALSEx__, respectively.
              * In the file tags-for7.in, the columns are reordered so
                that the boolean values appear last. Also, the values in
                these last two columns are always printed with exactly
                one space as separator. This is neccessary because the
                length of repr strings for booleans is variable (eg. 0
                versus False).
              * There are two different pickles; these are replaced by
                __xPICKLE1x__ and __xPICKLE2x__, respectively.
      * doc/test_examples.py is modified to ignore the .in files (line
        144).
      * A new shell script, doctest_preprocess, is introduced in the doc
        directory. It uses the python interpreter to determine the
        current python version and substitutes the special values in the
        test fragment template files with the appropriate values for
        that version, generating the real test fragment files.
      * The Makefile is modified in two ways:
              * The test target depends on the version target.
              * The version target runs the doctest_preprocess script.

> It makes me a little scared in that it has the potential to make things
> more flakey.

Since this solution still uses only hardcoded strings, I think little
can go wrong that would not cause the tests to fail, making the build
fail, alerting the user.

The solution can accommodate for many more differences among python
interpreters. I have only solved the issue for python 2.2 and 2.3,
because I do not intend to support 2.1 in the Debian packages.

However, I think this is not the optimal solution. A better solution
would be to rewrite the doctest_preprocess script in python, reducing
clutter and making the build process more consistent.

An even more elegant solution would be to merge the functionality of
that script into doc/test_examples.py. Two approaches could be taken:
the first would be to still use hardcoded strings but read them from eg.
doc/doctest/version_strings-x.y.py, where x.y would be the python
version and the file would define a dictionary of substitution strings.
Every substring of the .in files matching the regexp (__x.+x__) would be
replaced with the corresponding dictionary element.
The other approach would be to generate the strings at runtime.

I will apply this temporary fix to the Debian packages, even though it
does not aesthetically please me. I consider this fix merely a
workaround for the packages. Therefore, I will not include any patches
in this message. I don't want to see this solution in the original
version. :)

Instead, I intend to modify your build scripts so that they are more
general. The Debian package currently has a meaty .diff which changes
lots of small things that I think you'd be happy to change in the
original version. (Other things I'm not so sure about; you definitely
don't want to hear what I'm forced to do to make dia run even when there
is no $DISPLAY available... ;)

In any case, you can expect some patches for this and other build issues
in the future. If there's something you'd like me to consider, or some
part you'd like to modify yourself, then I'll be happy to continue this
discussion!

Cheers,
-- 
Fabian Fagerholm <fabbe at paniq.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://www.object-craft.com.au/pipermail/albatross-users/attachments/20031118/be5be2e1/attachment.pgp>