So I’m understanding this correctly, does the proposed @require @eval using ... pattern essentially give us the lazy glue code loading Requires is currently used for while not incurring most of the drawbacks of using Requires? Or is it providing something else/something far less powerful? If the former, that sounds like an amazing stopgap until we get proper conditional deps.
1 Like
A pure “Core” module to me only has types and no methods. In practice, you probably need some constructors and methods for the “Core” module to have any utility.
In one sense I agree with you that there should be few precompile statements in a “Core” package but that is mostly because there should not be much to precompile there to begin with.
Yes, that is essentially what I was proposing above.
It provides an opportunity to do precompilation caching of the glue code. One has to make sure that the interface package does indeed include precompile statements. As far as Julia is concerned the interface package is just a normal package.
1 Like
I guess as a short-term measure we could at least turn RecipesBase and StructTypes into plain dependencies.
For SentinelArrays, I wonder whether we could find a solution by adding an API to ArrayInterfaceCore. Indeed, the problem to solve is just that CategoricalArrays defines a copyto! method dispatching on the destination array, while SentinelArrays defines one on the source array. But all that’s needed is to call the general fallback defined in SentinelArrays, there’s no particular interaction between these two packages. If we could add an API to indicate that SentinelArrays should take precedence all would work fine.
Regarding JSON.jl, the only line behind @requires is JSON.lower(x::CategoricalValue) = JSON.lower(unwrap(x)). I don’t understand how it can causes invalidations. Care to explain?
1 Like
I’m not sure if the issue is that it’s causing invalidations. Rather there is no ability to cache the type inferred code anywhere for that method, potentially lengthening load times.
How does this look in practice? Can packages keep their @require PkgName=UUID using GluePkg statements at the top level, or does this require changes to code using Requires?
The @require statements have to go in __init__, as usual. But with @eval I don’t think there’s any barrier to doing this today, without any need for changes to Requires.jl. I’ve generally not bothered simply because when I’ve used Requires it’s mostly been to load a small amount of code, but there are cases where the precompilation would be very desirable.
2 Likes