Stream: helpdesk (published)

Topic: stacked environment issues


view this post on Zulip Eric Hanson (Jul 17 2025 at 12:49):

yeah. I think with JuliaSyntax and JuliaLowering, dev tools are now commonly depending on them (since they are really useful) and they are still in-development with breaking changes, so this is more of an issue now. Before I don't think there were many in-development shared deps between dev tools and it was less commonly an issue (except for the "everything in default env" situation).

view this post on Zulip Eric Hanson (Jul 17 2025 at 12:53):

it would be nice if it were easy for dev tools to have their own copies of their deps loaded like VSCodeServer does. E.g. ExplicitImports does not need to share the JuliaSyntax module or methodtable with Cthulhu, we just each need to be able to parse stuff. So if I could load my own copy of JS and skip the compat problems that would be better.

view this post on Zulip Eric Hanson (Jul 17 2025 at 15:19):

https://github.com/JuliaTesting/ExplicitImports.jl/pull/121

view this post on Zulip jar (Jul 17 2025 at 18:28):

The absolute state of my dev tools :woozy_face:

help?> JET.report_package
  No documentation found.

  Binding JET.report_package does not exist.

julia> JET.report
report_call     report_color
report_file     report_opt
report_package  report_text
reportkey

julia> :report_package  propertynames(JET)
true

julia> JET.report_package
ERROR: UndefVarError: `report_package` not defined in `JET`
Suggestion: check for spelling errors or missing imports.
Stacktrace:

view this post on Zulip Eric Hanson (Jul 17 2025 at 19:14):

for ExplicitImports I think my manual vendoring will work OK but in general it's very annoying if the version of the dependency you need depends on the Julia version (like PrecompileTools). Because in that case you're vendoring in multiple source copies and doing if VERSIONs to decide which to load etc - basically a manual reinvention of Pkg.resolve. Or if the dep itself has lots of dependencies and you need to vendor them all, or not.

I think the semantics I want is basically "add DepXYZ as a dependency to my project, but pretend it has a new name/UUID and is a separate package", and the same for all of its dependent packages. Maybe pkg> add DepXYZ --private or something could do that, with a [private-deps] toml section.

view this post on Zulip Eric Hanson (Jul 19 2025 at 17:13):

ExplicitImports.jl v1.13 now vendors JuliaSyntax (and AbstractTrees): https://discourse.julialang.org/t/ann-explicitimports-jl-tooling-to-help-use-and-maintain-explicit-imports-in-your-package/110973/20


Last updated: Jul 22 2025 at 04:56 UTC