Why not doing the test is_available here? People are not going to be happy to having to unconditionally download MKL, that was the whole point of #133 (which you seemed to agree with, judging by the 👍)

I was not aware of this issue. Mainly, I thought it would be more user-friendly to figure out the supported libraries in advance, before trying to set them. Only moving the check here won't help with my use case and the linked issue above.

Is there any other way to check whether a library can be loaded apart from ..._jll.is_available()? Maybe checking the system architecture is an OKish workaround?

Is there any other way to check whether a library can be loaded apart from ..._jll.is_available()?

No.

Maybe checking the system architecture is an OKish workaround?

That's going to hard-code answers which may potentially change over time.

Only moving the check here won't help with [...] the linked issue above.

Why not? Capture the fact that the artifact isn't available and throw a helpful error message to explain what to do, instead of getting a cryptic UndefVarError that some users don't know what to do with.

Also, if I understand this implementation correctly this is automagically changing the provider if the requested one isn't actually available, which doesn't sound very deterministic.

Yeah, switching to the supported default provider was the main point - changing the LocalPreferences.toml file manually on my end creates git conflicts when moving branches and pulling all the time (and if I forget to adjust it, compilation will fail). To some extent that's already done in the current code: If you specify an invalid provider other than fftw and mkl, FFTW will just display an @error and switch to the default provider (which is fixed to fftw currently). So basically I'm in the same situation, on my computer mkl is also an invalid provider so I would like to switch to the default one. And I guess you could hypothetically think about an analogous scenario where fftw is invalid and you would like to switch to the mkl as default provider.

Displaying a more descriptive error message is an improvement but I think a solution that just defines the (in)valid providers correctly would be much more convenient.

That's going to hard-code answers which may potentially change over time.

Yes, a bit annoying. But since I didn't see any other alternative to define the valid providers correctly, I switched to hardcoding the supported platforms.

I guess the supported platforms could always be updated easily - and probably supported platforms for MKL won't change much at least? If we're more ambitious, probably we could even automatically extract it from the Artifacts.toml files in FFTW_jll and MKL_jll.

I guess the supported platforms could always be updated easily - and probably supported platforms for MKL won't change much at least?

It did change.

If you do something like

const valid_fftw_providers = let
    platforms_providers = Dict(...)
    Base.BinaryPlatforms.select_platform(platforms_providers, Base.BinaryPlatforms.HostPlatform())
end

you avoid storing in the compile cache a useless dictionary.

Maybe provide a more helpful error message to explain how to to do this? Most users won't have a clue of what this is about.

#280 shows that the hardcoded list a bad idea: there's no MKL 2024 build for this platform.

Yeah, I always thought that a hardcoded list is suboptimal. Ideally we would just parse the Artifacts.toml file, I think, similar to https://github.com/JuliaPackaging/JLLWrappers.jl/blob/a1025a86bc58ac40e2d1df30f4d6bf6c390d51e1/src/toplevel_generators.jl#L132-L185 - but in the best case such a functionality would be available somewhere else. I would imagine that this would be a more common use case - figuring out whether a user's platform is supported without actually loading the JLL package.

But why not removing the automagic fallback, and only do what the user asks, and loudly and clearly fail if the artifact isn't available? In that case you can use is_available safely, since the user explicitly requested it

Because the motivation for the PR and the problem I was trying to solve was that it failed. As a user I don't want to run into an error, I just want to use the provider that is available on my platform.

See e.g. also https://julialang.slack.com/archives/C6A044SQH/p1701979919655409

To clarify a bit more: In my case the MKL provider was chosen as the default for me by a package I was using, but in principle it could also be the other way around (that the currently hardcoded default FFTW_jll provider does not work but MKL_jll does). I think it would be less surprising and more user-friendly if the default provider would not be hard-coded to e.g. FFTW_jll but that it is checked which providers are actually available for the user and the default one is chosen as the first one among those. I don't think one should override explicit user settings but I think the default should work (and the error messages/list of valid providers should match the ones that are actually available).

In my case the MKL provider was chosen as the default for me by a package I was using

I'm not sure packages should do that, preferences should be up to users. Especially if packages get it wrong.

I agree. But I want to emphasize that the PR tries to address the problem of incorrect lists of valid providers and non-working default providers in FFTW.jl itself, and does aim (anymore) to fix incorrect settings in some downstream package.