Julia package manager and JIT compiler precompilation cache reuse at integration boundary

Direct answer

Under the default depot layout, the package manager invalidates a precompile cache entry for a package when that package’s own version changes or when its manifest entry changes. A change in a transitive dependency does not, by default, invalidate the dependent’s cache entry if the direct dependency’s version and manifest entry remain unchanged. The cache key combines package version, manifest state, and the running Julia version; transitive dependency identity is not a standalone invalidation trigger under default settings.

Confirmed behavior versus likely explanation

Confirmed: cache entries are stored per environment in the depot and are keyed by package version, manifest state, and Julia version. Confirmed: source edits that do not alter version or manifest can leave previously compiled artifacts in use. Likely explanation: when a transitive dependency is updated but the direct dependency’s manifest entry is untouched, Pkg has no recorded reason to rebuild the dependent’s precompiled image, so the stale image may persist until a manifest or version change forces a rebuild.

Live code update tools and mixed execution

Tools such as Revise.jl operate outside the precompilation cache. They track source files by path and modification time and redefine bindings in the running session. Call sites that already resolved to functions from a cached precompiled image continue using that image unless the tool explicitly redefines those bindings. New invocations after an edit may execute revised source, while older call sites still reference cached compiled code. This produces a mixed execution state where some call sites use cached images and others use revised source. Revise does not automatically rebuild the precompile cache.

Version assumptions for cache reuse

Cache reuse assumes the package version, manifest entry, and Julia version remain unchanged. Source edits without a manifest change can still produce stale results if exported function signatures change, because callers compiled against the old signatures may continue linking to the old compiled code. Internal-only changes carry lower but not zero stale-result risk. Custom sysimages or PackageCompiler images alter these assumptions and are outside default depot behavior.

Steps for this case

1. Confirm the active depot: julia -e 'using Pkg; println(DEPOT_PATH)'
2. Inspect the compiled cache directory under that depot for the package’s precompiled artifacts.
3. If a transitive dependency changed without a manifest change and the dependent must be rebuilt, either bump the dependent’s version or update its manifest entry, then run Pkg.precompile(). Deleting the specific compiled cache file is a scoped alternative.

Missing diagnostic detail

Are you observing stale behavior after editing a transitive dependency’s source while its version and manifest entry remain unchanged? This determines whether the fix is a manifest bump or cache deletion, or simply expected live-update mixed-state behavior.

Assumptions and uncertainty

Behavior is version-sensitive across Julia releases and can differ with custom depot paths, sysimages, or PackageCompiler builds. The exact internal heuristic for transitive dependency invalidation is not treated as a documented contract here. This draft requires current verification against your Julia version before operational use.