I recently upgraded to Julia v1.13 and was pleasantly surprised by how quickly packages downloaded. However, Pluto fails to precompile on my machine, which didn’t used to happen on v1.12.7. It appeared that someone else was having this problem back with Julia v1.6, I preferred to ask again because the proposed solution was closer to a temporary hack than a real solution. I will be grateful for any help, as Pluto is a package i use a lot.
Below is the error message.
Sorry that I cannot help, but I’ll note that it’s odd that PlutoRunner.jl:372 from that stacktrace is a non-existent line in the source: Pluto.jl/src/runner/PlutoRunner/src/PlutoRunner.jl at main · JuliaPluto/Pluto.jl.
Looks like a different folder structure in the error message, would need to go to 0.19.32 or earlier: Pluto.jl/src/runner/PlutoRunner.jl at v0.19.32 · JuliaPluto/Pluto.jl · GitHub. So that begs the question, what is the version of Pluto and the rest of the environment (Pkg.status)?
When launching Pluto with 1.13, I received a message tellong that Pluto is not yet compatible with 1.13.
I believe that we have to be patient 
I also saw the warning message, but I’m currently running Pluto with Julia 1.13 and didn’t have any issues so far (I’m on Linux though, unlike the OP).
My Pluto version appears to v0.14.2.
I guess I will just have to downgrade (or wait) for sometime now.
Thank you for helping @Maucejo , Benny, Sevi and cstjean
For me 0.14.2 also errored, but the newest version 1.0.3 worked just fine – it does warn that 1.13 is not yet (fully) supported, sure, but for me it runs just fine.
whuh wa wait?! Pluto v1 has been released?
Damn, i must come out of my rock time to time. It works well enough here. Thanks kellertuer : )
So looking at the PlutoRunner.jl:372 line in that version:
370 # these deal with some inconsistencies in Julia's internal (undocumented!) variable names
371 const primary_world = filter(in(fieldnames(Method)), [:primary_world, :min_world]) |> first # Julia v1.3 and v1.0 resp.
372 const deleted_world = filter(in(fieldnames(Method)), [:deleted_world, :max_world]) |> first # Julia v1.3 and v1.0 resp.
373 const alive_world_val = getfield(methods(Base.sqrt).ms[1], deleted_world) # typemax(UInt) in Julia v1.3, Int(-1) in Julia 1.0
It looks for internal fields that obviously changed between Julia 1.0 and v1.3 and do not exist in 1.12 or 1.13. filter makes an empty Symbol[] in the latter cases, and first(Symbol[]) throws the reported BoundsError.
Some packages, including Pluto, have to use Julia internals to implement deep features like reactivity. The tradeoff is that those internals are free to change with patches or minor releases, so developers have to track and keep up with those changes. I’m not guessing here; a Pluto co-creator once publicly complained that using internal APIs (well, it’s debatable whether those were APIs to begin with, and it’s definitely not API outside of base Julia) leads to packages breaking (strictly speaking, that’s not what breaking means) and suggested Julia stabilize/constrain its internals into public API Pluto could use. One particular argument in favor of constraining internals was that Julia shouldn’t be a compiler experiment…which is kind of like saying an orange shouldn’t be a fruit.
A package developer who uses enough internals to risk frequent (informal) breakage could constrain their project to Julia versions they know to work. However, Pluto instead opts for a soft runtime warning. Evidently that does not work if Pluto is outdated to the point it fails to run, but as Maucejo, Sevi, and kellertuer mentioned, it does allow us to ignore the warning and try Pluto on newer Julia versions before the Pluto developers validate it.
Well, with newer tools like ExplicitImports.jl consolidating these things is more feasible than before, see e.g.
Add Aqua, UndocumentedNames and ExplicitImports checks · Issue #3472 · JuliaPluto/Pluto.jl · GitHub .
How can access to undocumented or non-public fields, including by symbol, be automatically detected? Method is a public name that comes with importing Core, so that alone won’t be flagged as an issue.
In the absence of corresponding language features, this can be done by tooling. ExplicitImports.jl helps to implement explicit import statements like using SparseArrays: sparse and, since Julia 1.11, to detect accesses to non-public names.
The Docs.undocumented_names method highlights the exported and public names of a package which miss docstrings.
Documenter.jl by default now errors if a documented name is missed in the documentation.
All this can be implemented in the CI of a package, and I try to maintain this as a standard in my packages, see e.g. ExtendableSparse.jl/test/alltests.jl at master · WIAS-PDELib/ExtendableSparse.jl · GitHub .
I skimmed the docs and read more or less the same information. I’m asking about struct fields specifically, not global variables, and not necessarily with dot notation. To paraphrase the erroring line, filter(in(fieldnames(Method)), [:deleted_world, :max_world]).
Ah ok I see your point. I also think this is missing.
I opened Check for struct field access without accessor functions ? · Issue #183 · JuliaTesting/ExplicitImports.jl · GitHub .