Would it be possible to switch to downloading qhull at build time, similarly as was done for jquery in #11246?

@anntzer It would certainly be possible.

What does it gain us? We ship 1220 kB of uncompressed Qhull source code, the compressed Qhull tarball is 1250 kB as it contains much more than we use. If we are worried about end-user bandwidth and we assume that mpl is obtained in a compressed format then the change is detrimental. Also, if we are downloading rather than shipping code, we have to write some extra code to download, extract and presumably cache the Qhull source code.

Given that the current process has worked fine for a number of years, changing to a more complicated solution seems like unnecessary re-engineering to me.

As explained in #11199 (comment):

Right now jquery weights 1.3Mb [qhull is basically the same size]; compare this with the baseline test images that weight ~50Kb each and that we are painstakingly trying to avoid adding to the repo.

Note that recently we even removed some commits from the main repo to get rid of 2.5Mb of extraneous baseline images.

The machinery in setup.py to download jquery (download_jquery_to) should be easily copypaste-adaptable to qhull.

I see that I have caused some test failures due to image differences. How do I get hold of the changed images? I have heard 'build artifacts' mentioned before, but I cannot see how to access them.

At least for AppVeyor there's a tab if you go to the details:

@timhoffm Thanks for that.

There was a difference in the mplot3d tricontour line plot; I have now updated the test image.

The explanation is that the new qhull algorithm returns a different permutation of the same triangulation, i.e. the same triangulation but with the triangles in a different order. In turn this means that tricontour gives a different permutation of closed line loop contours, i.e. a different start/end point for each closed loop. This makes no difference to 2D plots or indeed 3D filled tricontour plots, but evidently does for 3D line tricontour plots in that pixels near the start and end points of the closed loops are slightly different.

I thought the main reason behind getting jquery downloadable was so that users will use more recent versions of jquery, which gets updated fairly frequently, and has security implications. qhull doesn't update all that often and doesn't pose a similar security threat that jquery does.

qhull doesn't update all that often

This statement is unfortunately incorrect, as can be checked by comparing https://github.com/qhull/qhull/releases and https://github.com/jquery/jquery/releases (the release rate is basically the same in the past few years, even ignoring the "date" releases of qhull which appear to be dupes).

doesn't pose a similar security threat that jquery does.

I haven't audited either codebase, but it's not unlikely that there are vulnerabilities in qhull as well. Just from a quick search: who knows what can happen if you return a dangling pointer? (qhull/qhull#46)

Really, 1Mb doesn't look that big, but that's how you end up with a repo that's close to half a Gb...

In any case, I can implement the switch to on-demand-downloaded qhull, e.g. with 2015.2 (the current version) first. It's just a matter of waiting for #15430 to be merged first :-)

Image comparison test on tri_smooth_contour.png was failing on MacOS with a tolerance of 0.072 which is greater than the required tolerance of 0.07. I have rather crudely increased the test tolerance to 0.072 to see if all the CI tests pass now.

Proposed implementation of downloading-qhull-at-build-or-sdist-time in #16720.

Qhull 2020.1 is available on Github. It includes improvements to CMakeLists.txt and Makefile.
https://github.com/qhull/qhull/wiki

Replaced by #16720.