-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.11.1: breaking change in extension loading #56204
Comments
Juliahub search indicates that quite a few packages call get_extension in their extensions, so maybe this bug manifests itself somewhere else as well. Or maybe not, depends on the order I guess, didn't check myself. |
AFAIK |
Yeah, this is a bit unfortunate. The issue was that loading extensions in other extensions as was done previously was "unsound" and could easily cause "circular dependencies" leading to bad behavior like:
I didn't see any new regressions from PkgEval from backporting it which is why I assumed it wouldn't have a big impact on the ecosystem but maybe this was hidden by other errors. In hindsight it was probably wrong to backport it. The use case people want seem to basically be #48734 so we should probably work on fixing that feature. In the mean time the question is if we revert the extension loading change for 1.11.2. |
It's mentioned and explained in Pkg docs, https://pkgdocs.julialang.org/v1/creating-packages/. Afaiu, in 1.10 and earlier this means this function is public. As for loading, the same Pkg docs page writes that
Naturally, after loading MyPkg + WeakDepA I expect MyPkg -> WeakDepAExt to be loaded as well. So, I found a workaround: add
Unfortunately, yet another case of PkgEval not catching an actual issue :( Have to I say, I don't have a good understanding about it in practice. At least UnionCollections tests (example from the first post) tests succeed on 1.10 and 1.11.0, but fail on 1.11.1. |
I looked in the PkgEval log and UnionCollections is here: https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/0de7b6c_vs_501a4f2/UnionCollections.primary.log. And we can see the extension fails to load but the package tests end up passing anyway... |
Indeed, you are right, I wasn't looking carefully enough! Still not 100% used to seeing "big scary errors" that are practically just warnings :) |
I guess there is no test that checks that the function in the extension works? |
Indeed, maybe it slipped through the cracks over time... Anyway, I confirm that with |
Although, in some scenarios it leads to
... |
You might try using a guarded # workaround for https://github.com/JuliaLang/julia/issues/56204
function __init__()
if !Base.generating_output()
Base.eval(quote
const DictionariesExt = Base.get_extension(UnionCollections, :DictionariesExt)
FlexiMaps.mapview(f, d::DictionariesExt.UnionDictionary) = @modify(vs -> mapview(f, vs), DictionariesExt._values(d))
# TODO disambiguation:
# FlexiMaps.mapview(p::Union{Symbol,Int,String}, A::UnionDictionary) = mapview(PropertyLens(p), A)
end)
end
end
Using |
I think the above workaround works with an appropriate pre-compile guard (the |
Another affected package is Transformers.js which relies on Flux's CUDA extension in its own CUDA extension. https://github.com/chengchingwen/Transformers.jl/blob/master/ext/TransformersCUDAExt/TransformersCUDAExt.jl It compiles just fine but crashes in runtime with |
Not too often I see packages broken by patch versions of Julia, but it's one of those cases :(
As a specific example,
using UnionCollections, Dictionaries, FlexiMaps
throwsERROR: LoadError: type Nothing has no field UnionDictionary
on this line: https://github.com/JuliaAPlavin/UnionCollections.jl/blob/0000000018ecd297a2e7448671da83c035b3da4c/ext/FlexiMapsDictionariesExt.jl#L8.Effectively, it does
get_extension(MyPackage, :WeakDepA)
in the extension for WeakDepA + WeakDepB.Judging by the documentation, it should work:
get_extension
returns the extension if it's loadedIn the specific case with UnionCollections, this is what I expect to happen on that
using
line:And that's indeed how the observable behavior worked on earlier Julia versions, including 1.11.0. But not on 1.11.1.
The text was updated successfully, but these errors were encountered: