downloader for ausaxs silently fails and then fails the CI tests later

[llimeht]

Describe the bug
build_tools/get_external_dependencies.py attempts to download ausaxs; this has been failing today, but the error is suppressed in the download.

However, ausaxs is needed unconditionally by the tests, so suppressing the download error just means that CI carries on for ages and then fails with an obscure error about ausaxs later.

To Reproduce
Steps to reproduce the behavior:

1. it's a random failure, it's not reproducible.
2. See recent CI https://github.com/llimeht/sasview/actions/runs/15456346371/job/43509300786#step:13:42

Expected behavior
Either fail early, or don't fail at all - make the ausaxs tests not fail if it's not available, or fail CI at download time

SasView version (please complete the following information):

• Version: release-6.1.0 branch

Operating system (please complete the following information):

• OS: all - download failure randomly occurs on any arch

Additional context
I really don't like downloading precompiled stuff like this at build time - we have pip for that. The best option would be for an ausaxs python wrapper to be installed as an arch-dependent wheel. Is that on the cards? Embedding pre-compiled things into the wheel is also problematic - we need to think about this some more... there are a few other bugs to fix because of this.

[klytje]

Is this a common issue? AUSAXS has been in SasView for the better part of a year by now, and this is the first time I'm seeing failing tests because of it.

Should AUSAXS either be unavailable or crash at runtime, the calculations will fall back to using the original SasView implementation. That's why the tests explicitly checks if the library is present; otherwise they would always succeed and we'd never know of any issues.

#3194 relies on the current behaviour of get_external_dependencies to attempt to download the library at runtime if it is not present for developers, since the library is not shipped with the source distribution of SasView.

The library hooks are specifically designed only for SasView, so a separate Python wrapper is not currently being worked on. What are these additional bugs we need to fix?

[llimeht]

Intermittent issues are the worst — if CI is going to fail, then fail fast is better than continuing on to fail later, and it's most important to fail with the actual error and not some unrelated downstream error. The short term path to less annoyance (from time wasted by looking at why tests are failing) is to not suppress the download error, since it is the download error that is failing CI, not test failures. The run-time downloading of libausaxs in #3194 can catch failures and suppress them there, rather than suppressing them for all use cases — that looks like an easy upgrade.

The bigger question of how best to provide the library to the sasview code has a few things to consider and probably should move to something other than this bug about the downloader not fast-failing CI. To pop down some thoughts right now though, which can get copied over to a github discussion or similar soon...

• It's great that there's a Python fallback for ausaxs in the code, but it can't be used and sasview can't be packaged that way if libausaxs is a build-time, hard dependency that is downloaded and embedded into the packages as is currently coded. The fallback speaks to a plan to be an "opportunistic plugin" or "optional dependency", which would be great. It's just not how things are currently implemented. I look at that and suspect that we're not actually a million miles away from wanting exactly the same thing here and just need to align the implementation to fit that vision.
• Something that is installable via pip is the best option because that's the way that all other dependencies are installed and can be marked as an optional dependency. Having only one step to install the dependencies and for it to be the 'normal' way all Python packages work is important for having a lower barrier to entry for new contributors, and also for maintaining a simple build system for ourselves. @jamescrake-merani and I were talking about what that would look like and it would be very simple to put together either a pyausxas or sasview_auxsas or sasview_extension_auxsas to match the quite sasview-specific nature you describe. There's nothing wrong with it being sasview-specific and on pypi.
• if it's impossible for libausaxs to be turned into a normal python package, perhaps making the download occur at runtime when needed - at point of use as a "plugin downloader" could work? The code changes for that would be quite minimal and I can see you've already done lots of that in Support for SAXS fitting #3194; that lets us move the plugin download out of the build system which is great.
• The sasview code (and therefore the wheel) is currently platform-independent (aka pure python package) meaning that the same sasview distributable works everywhere. The platform-dependent code is in the dependencies like SciPy and PySide6, but have a look at the 36 different wheels that SciPy releases that mean it works across operating systems (and across Python versions, relevant to scipy but not to ausaxs). SasView being platform-independent is an important simplification for the build process and for distribution. It let us move from mac-intel to mac-arm64 with minimal fuss and likewise lets us use SasView on windows-arm machines, arm64 linux, riscv64 linux with no additional work. If the sasview wheel ends up with a library embedded in it (rather than the library being installed via pip or via a plugin mechanism), we lose all that, and we also need build wheels on multiple platforms (for which we don't currently have the infrastructure).

A couple of side issues I noticed

• the current libausaxs distribution has a pretty limited set of platforms - that might need to be enlarged some time
• it also links against things like libcurl and through that quite a lot of other http/https libraries which I found a bit unusual to see for what I thought was a calculation engine; my knowledge of its internals is limited though

[klytje]

1. I originally added the fallback to avoid having my untested library as a hard dependency. Without that, users with weird setups or on unsupported systems (e.g., older systems without AVX256 vector instructions) would literally be unable to use SasView, as failing to load my library would mean a hard crash in SasView itself. That's also why the library is first loaded and called from a separate process, to avoid propagating possible segfaults and corrupting the main SasView process. But the goal is to include it by default.

2. I'm not at all opposed to this approach; I just don't know how to do this. I think it'd be a great way to fix it. Throwing an exception when failing the download is also an option for now.

3. Downloading it on the fly is definitely also an option, but it would lock out users who download SasView and then use it only in closed environments without internet access. We discussed this a while ago, and apparently it's a large enough concern that I had to add offline-support to my library for Support for SAXS fitting #3194.

4. Note that my library is not being pulled into the uncompiled script version of SasView; only the binary installers, where it supports all current platforms (the single MacOS dylib is a universal library supporting both intel and arm64). This is another reason why the fallback is necessary: without it, unsupported platforms cannot use SasView.

5. It shouldn't be too difficult to expand; the project is pure C++ with only curl as an external dependency. Currently it's mostly limited by the platforms supported by the GitHub runners.

6. AUSAXS is a full-fledged separate program similar to CRYSOL. I just noticed that the original Debye calculations in SasView were very inefficient, and decided to expose those calculations in my highly optimized program as a shared library for SasView to access. While curl is not internally used for the current calculations, it will be after Support for SAXS fitting #3194. Note also that curl is statically linked on Windows, since it is not typically available by default there.