build/pkgs/nauty: Update to 2.8.8; use VERSION in all upstream_urls.

[mkoeppe]

https://pallini.di.uniroma1.it/changes24-28.txt

Also, motivated by a mistake I made while preparing this PR (#36774 (comment)), and previously in #35380 (see #36781), and countless other times, I am changing all upstream_urls to use VERSION instead of the hardcoded version number. This makes it less error-prone to use sage -package update SPKG NEW_VERSION and sage -package update-latest. These commands now also display the URL from which they are downloading the tarball, and they warn if the upstream_url field does not contain the VERSION variable.

(Exceptions: ipykernel, which is fixed in #36129, and libbraiding, which is fixed in #36781)

Because some of the upstream_url need the version in a different format, a mechanism to refer to the components of a version is added: The strings VERSION_MAJOR, VERSION_MINOR, VERSION_MICRO can be used. For added readability, instead of the naked strings, also the notation ${VERSION_MAJOR} etc. can be used. For example, nauty, which previously had to use a hardcoded version number, now uses the upstream URL pattern
upstream_url=https://pallini.di.uniroma1.it/nauty${VERSION_MAJOR}_${VERSION_MINOR}_${VERSION_MICRO}.tar.gz

The syntax ${VERSION_MAJOR}, borrowed from Bourne shell, matches what sage-bootstrap already uses in https://github.com/sagemath/sage/blob/develop/.upstream.d/10-SAGE_SERVER

📝 Checklist

• The title is concise, informative, and self-explanatory.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation accordingly.

⌛ Dependencies

• Depends on fix doctest for nauty 2.8.8 #36771 (merged here)

[mkoeppe]

File "sage/graphs/generators/families.py", line 3678, in sage.graphs.generators.families.nauty_gentreeg
Failed example:
    [len(list(graphs.nauty_gentreeg(str(i)))) for i in range(1, 15)]
Expected:
    [1, 1, 1, 2, 3, 6, 11, 23, 47, 106, 235, 551, 1301, 3159]
Got:
    [1, 0, 1, 2, 3, 6, 11, 23, 47, 106, 235, 551, 1301, 3159]
**********************************************************************

[mkoeppe]

@orlitzky Is this what nauty-2.8.6-gentreeg-gentourng.patch was fixing? Do we have a newer version of this patch?

[orlitzky]

That's an upstream patch from right after the v2.8.6 release. I only included it because the maintainer didn't think it was worth a new bugfix release, and, since v2.8.6 just happened, we might have been waiting a while.

It shouldn't be necessary in nauty 2.8.7 or newer.

[orlitzky]

It does appear in the changelog for v2.8.8:

• Fixed gentreeg output for n=2, also corrected the table of counts
  in the source file, which was shifted by 1. Also gentourng -c 2.
  Thanks to Gonne Kretschmer for reporting these.

[mkoeppe]

Sorry for the noise, I found my mistake.

[dcoudert]

LGTM (passes all tests on Fedora 35) but some failures are reported by the CI on specific systems.

[mkoeppe]

The failures of the "sitepackages" runs can be ignored -- many fail systematically, and we are reducing them in #36697.

I've restarted the other CI Linux incremental runs, which got interrupted

[dimpase]

Why do we need to delay these variable substitutions until after the run of ./configure ?

At ./configure time the versions are known, so there is no need to reimplement autotools in Python...

[mkoeppe]

You're in the wrong phase. ./sage -package operates on unconfigured, unbootstrapped source trees.

[dimpase]

there is no need for this extra complication.

[mkoeppe]

At least, Dima, you would need to say what exactly it is that you are against.

[dimpase]

it's weird that on one hand each package directory has files with templates which are filled by configure, as well as with templates filled in by an ad hoc script. The latter in particular has data uniquely identifying the package (from checksums).

There is no reason not to rewrite the templates in the latter along with filling in the checksums.

There is also no reason to insist on the ability to fill in the latter templates in an unconfigured tree (and so they can be filled in by configure).
The advantage is that then there is no need for tricky custom code to do the filling in.
The only disadvantage is that the current templates don't adhere to the usual autoconf syntax, but this is easy to fix, once and for all.

[mkoeppe]

Do you understand that using VERSION is already our existing practice?

[mkoeppe]

it's weird that on one hand each package directory has files with templates which are filled by configure

It does not. Yes, there are .in files, but they have nothing to do with configure.

[dimpase]

and all of our existing practices are absolutely the best possible, and any attempt to talk about changing them is a violation of CoC?

[mkoeppe]

Well, Dima, trying to mock me for holding you to the Code of Conduct, which applies to everyone, is certainly a Code of Conduct violation. Please do better.

[mkoeppe]

There is also no reason to insist on the ability to fill in the latter templates in an unconfigured tree (and so they can be filled in by configure).

Separation of phases is very important for maintainability.

Specifically, note that when bootstrap downloads a configure tarball, it goes through this very substitution mechanism for determining the download URL. So this cannot depend on running the configure script.

[mkoeppe]

I had to add one commit so that sage --package download understands the option --no-check-certificate, which is used in the CI.

[github-actions]

Documentation preview for this PR (built with commit b830776; changes) is ready! 🎉

[jhpalmieri]

Looks fine.

[mkoeppe]

Thanks!

[mkoeppe]

@vbraun Apparently the tarball is missing on the mirrors.
https://github.com/sagemath/sage/actions/runs/7761817689/job/21171029322#step:4:3901

[vbraun]

OK uploaded