This question came up in update to StaticArrayInterface by ChrisRackauckas · Pull Request #165 · ranocha/SummationByPartsOperators.jl · GitHub. @ChrisRackauckas submitted a patch to update my package from ArrayInterface.jl to StaticArrayInterface.jl. On Julia v1.9, StaticArrayInterface.jl uses package extensions to load code for StaticArrays.jl. On Julia v1.8, it uses Requires.jl, see
StaticArrayInterface.jl/StaticArrayInterface.jl at 73d2695ec3a875f4737662d40effa556ec61b81e · JuliaArrays/StaticArrayInterface.jl · GitHub
While precompiling my package, the code for StaticArrays.jl is not loaded, even if I call StaticArrayInterface.__init__()
manually.
- Is there a way to fix this behavior, i.e., to load the code for StaticArrays.jl into StaticArrayInterface while precompiling my package?
1 Like
I have good news and bad news. The good news is that I went quite deep down this rabbit hole while working on
Re-integrate NNlibCUDA as a package extension by ToucheSir · Pull Request #445 · FluxML/NNlib.jl · GitHub. The bad news is that it ended up at Package extensions for Julia < 1.9 - #17 by ToucheSir. TL;DR there isn’t much interest in having the Requires.jl fallback precompile.
It appears to me that part of the grand bargain of package extensions was that migrating from Requires.jl would at least be latency-neutral because the problems with precompilation were already present in the existing codebase. Adding new code under a @require
block breaks that agreement, which is why I gave up on the aforementioned NNlib PR as-is. Perhaps StaticArrayInterface was not aware of this caveat when they added the Requires path?
1 Like
Thanks a lot! So there isn’t really anything I can do… I will wait whether there are better ideas but the only options seem to be
- Do not upgrade to StaticArrayInterface.jl (bad because the SciML ecosystem is moving)
- Precompile only on Julia v1.9 and newer (bad because it degrades latency on Julia v1.8)
- Bump the required version of Julia to v1.9 (bad because I still support the LTS v1.6)
I don’t really like any of these. I guess there is no convenient way to make the set of dependencies depend on the Julia version?
We can change the <v1.9 path to not use requires and just make both extensions hard deps when weak deps are not available.