# Pluto fails to precompile on v1.13

**URL:** <https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450>\
**Category:** General Usage\
**Tags:** precompilation, regression, pluto\
**Created:** [September 13, 2026, 10:39pm UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450 "2026-09-13T22:39:01Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![lazylavenders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lazylavenders/32/222019_2.png) [@lazylavenders](https://discourse.julialang.org/u/lazylavenders)\
**Post date:** [September 13, 2026, 10:39pm UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/1 "2026-09-13T22:39:01Z")

</div>

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.

 ![Screenshot 2026-09-14 035738](https://global.discourse-cdn.com/julialang/original/3X/7/1/71cb54d009b9bfaa90aae4b7a6222869c34a743e.png)

---

<div class="post-metadata">

**Author:** ![cstjean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cstjean/32/1444_2.png) [@cstjean](https://discourse.julialang.org/u/cstjean)\
**Post date:** [September 14, 2026, 12:38am UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/2 "2026-09-14T00:38:57Z")

</div>

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](https://github.com/JuliaPluto/Pluto.jl/blob/main/src/runner/PlutoRunner/src/PlutoRunner.jl).

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [September 14, 2026, 4:52am UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/3 "2026-09-14T04:52:40Z")

</div>

> [@cstjean](#):
>
> a non-existent line in the source:

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](https://github.com/JuliaPluto/Pluto.jl/blob/v0.19.32/src/runner/PlutoRunner.jl). So that begs the question, what is the version of Pluto and the rest of the environment (`Pkg.status`)?

---

<div class="post-metadata">

**Author:** ![Maucejo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maucejo/32/39090_2.png) [@Maucejo](https://discourse.julialang.org/u/Maucejo)\
**Post date:** [September 14, 2026, 5:02am UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/4 "2026-09-14T05:02:18Z")

</div>

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 🙂

---

<div class="post-metadata">

**Author:** ![Sevi](https://avatars.discourse-cdn.com/v4/letter/s/c67d28/32.png) [@Sevi](https://discourse.julialang.org/u/Sevi)\
**Post date:** [September 14, 2026, 9:00am UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/5 "2026-09-14T09:00:25Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![lazylavenders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lazylavenders/32/222019_2.png) [@lazylavenders](https://discourse.julialang.org/u/lazylavenders)\
**Post date:** [September 14, 2026, 11:14am UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/6 "2026-09-14T11:14:25Z")

</div>

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 🙂

---

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [September 14, 2026, 11:18am UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/7 "2026-09-14T11:18:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![lazylavenders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lazylavenders/32/222019_2.png) [@lazylavenders](https://discourse.julialang.org/u/lazylavenders)\
**Post date:** [September 14, 2026, 11:52am UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/8 "2026-09-14T11:52:45Z")

</div>

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 : )

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [September 14, 2026, 5:11pm UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/9 "2026-09-14T17:11:08Z")

</div>

> [@lazylavenders](#):
>
> My Pluto version appears to v0.14.2.

So looking at the `PlutoRunner.jl:372` line in that version:

```julia-auto
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.

---

<div class="post-metadata">

**Author:** ![j-fu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/j-fu/32/11373_2.png) [@j-fu](https://discourse.julialang.org/u/j-fu)\
**Post date:** [September 15, 2026, 1:05pm UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/10 "2026-09-15T13:05:53Z")

</div>

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](https://github.com/JuliaPluto/Pluto.jl/issues/3472) .

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [September 15, 2026, 10:10pm UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/11 "2026-09-15T22:10:19Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![j-fu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/j-fu/32/11373_2.png) [@j-fu](https://discourse.julialang.org/u/j-fu)\
**Post date:** [September 16, 2026, 5:24am UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/12 "2026-09-16T05:24:07Z")

</div>

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](https://github.com/WIAS-PDELib/ExtendableSparse.jl/blob/master/test/alltests.jl) .

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [September 16, 2026, 6:00am UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/13 "2026-09-16T06:00:30Z")

</div>

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])`.

---

<div class="post-metadata">

**Author:** ![j-fu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/j-fu/32/11373_2.png) [@j-fu](https://discourse.julialang.org/u/j-fu)\
**Post date:** [September 16, 2026, 11:16am UTC](https://discourse.julialang.org/t/pluto-fails-to-precompile-on-v1-13/139450/14 "2026-09-16T11:16:25Z")

</div>

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](https://github.com/JuliaTesting/ExplicitImports.jl/issues/183) .