sage: update tests to adapt to matplotlib and sphinx upgrades

[collares]

Motivation for this change

Sage is currently broken on Nixpkgs master because the Matplotlib upgrade from #119008 just graduated from staging-next.

ZHF: #122042
@NixOS/nixos-release-managers

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[collares]

Sage uses Sphinx 3.1.0, and a Sphinx upgrade (#119648) just graduated from staging-next as well. The new version sprinkles a bunch of <span class="pre"> around, which looks like a harmless change, so I just updated Sage test expectations for that too.

[collares]

Note that Sage upstream is already proceeding with a migration to Sphinx 4 (https://trac.sagemath.org/ticket/31696), and the patch I added here is mirrored there. Should I fetchpatch this single commit from the ticket given that it matches the patch exactly, even if it's part of a larger update we don't want to do at the moment?

[collares]

Result of nixpkgs-review pr 123698 run on x86_64-linux 1

3 packages built:

• sage
• sageWithDoc
• tests.trivial

[collares]

@ofborg build sage sageWithDoc

[collares]

sageWithDoc times out because it doesn't run in parallel. Also, there's a weird "permission denied" error on ofBorg x86-64_linux when copying a CSS file that's probably related to matplotlib but it doesn't seem fatal.

[jonringer]

cc @timokau

[timokau]

Thanks for staying on top of this @collares. I think it would be nice to have some reference to the upstream sphinx ticket. I would prefer fetching the patch from the ticket (to indicate that a similar change is at least considered upstream). Mostly I would like to see a comment that refers to the ticket though.

[collares]

@timokau Done. Many thanks for the review!

Edit: I didn't realize the Sphinx 4 patch was not exactly the same as what I had!

-    <span class="sig-name descname"><span class="pre">numerical_approx</span></span><span class="sig-paren">(</span><em class="sig-param"><span class="n"><span class="pre">prec</span></span><span class="o"><span class="pre">=</span></span><span class="default_value"><span class="pre">None</span></span></em>, <em class="sig-param"><span class="n"><span class="pre">digits</span></span><span class="o"><span class="pre">=</span></span><span class="default_value"><span class="pre">None</span></span></em>, <em class="sig-param"><span class="n"><span class="pre">algorithm</span></span><span class="o"><span class="pre">=</span></span><span class="default_value"><span class="pre">None</span></span></em><span class="sig-paren">)</span>...
+    <code class="sig-name descname"><span class="pre">numerical_approx</span></code><span class="sig-paren">(</span><em class="sig-param"><span class="n"><span class="pre">prec</span></span><span class="o"><span class="pre">=</span></span><span class="default_value"><span class="pre">None</span></span></em>, <em class="sig-param"><span class="n"><span class="pre">digits</span></span><span class="o"><span class="pre">=</span></span><span class="default_value"><span class="pre">None</span></span></em>, <em class="sig-param"><span class="n"><span class="pre">algorithm</span></span><span class="o"><span class="pre">=</span></span><span class="default_value"><span class="pre">None</span></span></em><span class="sig-paren">)</span>...

Top is the new test output from the Sphinx 4 upstream update patch, bottom is the new output from my patch. The very first tag (<code> instead of <span>) is the only difference, but it's a bit embarrassing that I didn't catch it before considering it's the very first thing in the line :) I reverted to using my patch, but added a comment pointing to the ticket.

[jonringer]

got another failure:

sage -t --random-seed=0 /nix/store/g9qqb1v5yhsnagy9ybf5c6vhlix3xvnr-sage-src-9.3/src/sage/misc/sagedoc.py
**********************************************************************
File "/nix/store/g9qqb1v5yhsnagy9ybf5c6vhlix3xvnr-sage-src-9.3/src/sage/misc/sagedoc.py", line 23, in sage.misc.sagedoc
Failed example:
    with open(docfilename) as fobj:  # optional - dochtml
        for line in fobj:
            if "#sage.symbolic.expression.Expression.numerical_approx" in line:
                print(line)
Expected:
    <span class="sig-name descname"><span class="pre">numerical_approx</span></span><span class="sig-paren">(</span><em class="sig-param"><span class="n"><span class="pre">prec</span></span><span class="o"><span class="pre">=</span></span><span class="def>
Got:
    <code class="sig-name descname"><span class="pre">numerical_approx</span></code><span class="sig-paren">(</span><em class="sig-param"><span class="n"><span class="pre">prec</span></span><span class="o"><span class="pre">=</span></span><span class="def>
    <BLANKLINE>
**********************************************************************
1 item had failures:
   1 of   4 in sage.misc.sagedoc
    [10 tests, 1 failure, 7.67 s]

[collares]

@jonringer Thanks for testing! I made a mistake when updating the patch, but it should be fixed now, as described in the edit of my previous comment. I am also running nixpkgs-review to be sure. The current version is the one reviewed by timokau, with an extra comment as suggested.

[collares]

Result of nixpkgs-review pr 123698 run on x86_64-linux 1

2 packages built:

• sage
• sageWithDoc

[jonringer]

LGTM

Result of nixpkgs-review pr 123698 run on x86_64-linux 1

2 packages built:

• sage
• sageWithDoc

[collares]

Thank you @jonringer!

[timokau]

I reverted to using my patch, but added a comment pointing to the ticket.

Sounds good. Thanks @jonringer for taking care of the merge before branchoff :)