Skip to content

Don't rely on Pkg being present in the juliac env#138

Open
asinghvi17 wants to merge 7 commits into
JuliaLang:mainfrom
asinghvi17:patch-1
Open

Don't rely on Pkg being present in the juliac env#138
asinghvi17 wants to merge 7 commits into
JuliaLang:mainfrom
asinghvi17:patch-1

Conversation

@asinghvi17
Copy link
Copy Markdown

This way we rely on the stdlib lookup of Pkg (e.g. julia -e 'using Pkg' just works), and then activate the project in question.

This way we rely on the stdlib lookup of Pkg (e.g. `julia -e 'using Pkg'` just works), and then activate the project in question.
Comment thread src/compiling.jl Outdated
Comment thread src/compiling.jl Outdated
@topolarity
Copy link
Copy Markdown
Member

Seems like this should be handled with JULIA_LOAD_PATH rather than changing the --project

asinghvi17 and others added 2 commits May 12, 2026 13:31
Reverts 3510d24, 52b7c7f, and fe3dcaf. The Pkg.activate(only(ARGS))
workaround will be replaced with a JULIA_LOAD_PATH-based fix.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
When JuliaC is invoked as a Pkg app, the Pkg-app shim points
JULIA_LOAD_PATH at JuliaC's own env so that JuliaC's deps resolve.
That env var is inherited by the Julia subprocess we spawn to run
`Pkg.instantiate(); Pkg.precompile()` on the user's project, which
leaks two ways:

  1. `using Pkg` resolves via JuliaC's env (which today happens to
     have Pkg as a direct dep — but we shouldn't have to rely on
     that), and
  2. the user's project is effectively shadowed by JuliaC's
     manifest during precompile resolution.

Mirror the pattern PackageCompiler.jl uses (see PackageCompiler.jl
`ensurecompiled` / `run_precompilation_script`) and pin

    JULIA_LOAD_PATH = "<user_project>:@stdlib"

(with the trim prefs env appended when applicable). The user's
project goes first so `using <UserDep>` resolves via its
Project/Manifest; `@stdlib` guarantees `using Pkg` resolves to the
bundled Pkg regardless of whether the user's project lists Pkg as a
direct dep. We still pass --project=\$project_arg so that
Pkg.instantiate() / Pkg.precompile() target the user's project via
Base.active_project().

Addresses topolarity's review on JuliaLang#138 to handle this with
JULIA_LOAD_PATH rather than by switching to Pkg.activate(ARGS).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Comment thread src/compiling.jl Outdated
@gbaraldi
Copy link
Copy Markdown
Member

Looks pretty reasonable

@asinghvi17 asinghvi17 marked this pull request as ready for review May 14, 2026 01:49
@topolarity
Copy link
Copy Markdown
Member

I am a bit confused. The leading :/; is there specifically for this reason:

$ JULIA_LOAD_PATH=":test" julia -e "println(Base.LOAD_PATH)"
["@", "@v#.#", "@stdlib", "test"]

Are we inheriting a JULIA_LOAD_PATH from somewhere else? Maybe we just need to set it to nothing so that it's not inherited?

@asinghvi17
Copy link
Copy Markdown
Author

Hm it could have been inherited from the running process, so maybe we should set it to nothing?

@topolarity
Copy link
Copy Markdown
Member

Yeah, that sounds reasonable to me

I think Pkg app scripts set this: https://github.com/JuliaLang/Pkg.jl/blob/43dcd1fc05ef312f837e714a7f09b1b5616ae9f2/src/Apps/Apps.jl#L519-L520

…rocess

When JuliaC is invoked as a Pkg app, the Pkg-app shim sets
JULIA_LOAD_PATH to JuliaC's own env. That value gets inherited by
the Julia subprocess we spawn for Pkg.instantiate/precompile, so the
subprocess's LOAD_PATH becomes just JuliaC's env — no @stdlib, no @ —
and `using Pkg` (along with anything else in startup.jl, like
`using REPL`) fails unless JuliaC happens to list it as a direct dep.

Per topolarity's review, set JULIA_LOAD_PATH => nothing in the env
overrides so Julia falls back to its default load path. The leading
`:` trick is preserved for the trim case, which appends the temp
prefs env to the default.

Verified locally by setting parent JULIA_LOAD_PATH=<juliac-env> and
running compile_products on test/AppProject; previously crashed in
the subprocess startup, now succeeds.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants