-
-
Notifications
You must be signed in to change notification settings - Fork 358
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
[BUG] IJuliaExt causes problems with IJulia in default environment #4719
Comments
I tend to agree. @t-bltg what is your opinion? |
Thanks for the detailed explanation. |
So AFAIK you rely on environment stacks in order for the kernel to find IJulia, is it something common ? As you say, normally, if your project uses IJulia, it should IMO be put in the project Project.toml. |
Indeed it should. The problem is, one often has quite a few Project.toml files (different deps in different projects/notebooks), and so they will require different IJulia versions (esp. with tutorials, that have longer-lived Project.toml/Manifest.toml files, of with output "archived" for data preservations resp. scientific reproducibility). Unfortunately. only one of these IJulia versions can be referred to by the Jupyter IJulia "kernel.json" file (few people use lots of separate custom kernel files). This results in warnings if the IJulia version used by a given project differs from the one in the Jupyter "kernel.json" - and can result in trouble if the versions are too different. Keeping IJulia in the default environment and out of project-specific environments has worked well for me so far as a way of avoiding this. It's also natural approach, I would say, because the notebook code rarely used IJulia, so it's not really a dependency of the project. IJulia is unique here, I would argue, since it get's injected as an additional dependency in notebooks (without any |
Should be fixed on julia 1.9 with JuliaLang/julia#48352 I think. We probably should update compat once that is released. |
Oh, that is very nice! |
Seems fixed now with v1.9-rc3. |
I was mistaken, the problem persists in Julia v1.9-rc3. :-( |
Also a problem in Julia v1.9.0 |
Same error as described above on 1.9.0. We see it everywhere, because we use Quarto to produce our stakeholder reports (which uses IJulia under the hood). What are some temporary solutions?
|
Can we just use Requires for now until this is sorted out on the Julia side? This issue is really annoying and hits new users especially hard. |
Where is the julia issue tracking this ? |
I guess it was supposed to be JuliaLang/julia#48352, only for some reason that doesn't seem to do the trick ... |
Someone should open a dedicated issue in julialang/julia in order to make upstream Julia devs aware of this problem which might not have been taken into account while designing extensions. |
I'll do it. |
@KristofferC , is there a workaround for this problem in the extensions world it should we fall back to using Requires again on 1.9 ? |
If there's no other workaround I think #4749 should do the job for now. I play a bit with it, TTFP doesn't noticeably increase (subjectively). |
I'll have to dig into what is going on here before being able to provide a fix/workaround. For now, going back to Requires if that works seems like the best solution indeed. |
If you want to keep the extension, I think a workaround is to replace
|
Sorry for the delay - @KristofferC , your workaround seem to do it's job perfectly! :-) |
* Always use Requires for IJulia Addresses issue #4719. * Move non-IJulia-dependent code out of IJuliaExt.jl Reduces code loaded by @require while handling IJulia via Requires only. * Handle IJulia via extension if possible, but use Base.require * Formatting update ext/IJuliaExt.jl Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
I think we can close this now. :-) |
@BeastyBlacksmith could we release a Plot v1.38.14 to get this fix out? There is e4f1978 but Registrator doesn't seem to have been run on it. |
Thanks @t-bltg ! |
This sounds more like JuliaLang/julia#51280 (comment) |
Ah yes it might well be, I saw the |
Yes, it's any precompilation. Btw. it has been fixed but the fix hasn't made it into beta3 (see the issue). So, hopefully, it will make it to beta4! A simple fix that works most of the time is to call |
Details
IJulia is a bit peculiar in that you can really only have one version of it at the same time, otherwise one get's these "IJulia version doesn't match ..." warnings. This is because the (default) Jupyter kernelspec is bound to a specific IJulia version (since "kernel.json" points to
".julia/packages/IJulia/SOME_VERSION/src/kernel.jl"
). So one (at least me) typically keeps IJulia in the default (e.g. "v1.9") environment and out of specific project environment like the the "Project/Manifest.toml" kept next to a notebook.This leads to the following problem with the current Plots version on Julia v1.9, though:
This is very inconvenient, the only solution seems to be having IJulia in the notebook environment, but this would require having a separate Jupyter kernel for each notebook environment as well (or at lease having quite a few kernels). It's also really confusion to (esp. newer) users, because they can run
using IJulia
in the same notebook beforeusing Plots
cell without error, so IJulia is "there" (just not in an extension-compatible way).IJulia is special here because it's automatically loaded without being part of the notebook, and because the "kernel.json" issue, Plot's other Pkg-extensions don't have to be this problem.
I would suggest the we handle IJulia via Requires again. Most (all)
..._ijulia_...
function in "IJuliaExt.jl" could be defined in Plots itself, since they don't depend on IJulia, so Requires would only need to load a few lines IJulia-specific code.Backends
Not backend-specific.
Versions
Plots.jl version: v1.38.9
Backend version (
]st -m <backend(s)>
): Not backend-specificOutput of
versioninfo()
:The text was updated successfully, but these errors were encountered: