Port merge-project guard to Julia 1.4-1.10 variants - #120
Conversation
The julia-1.11 variant of activate_set.jl only raises "can not merge projects" when the working manifest already holds a different entry for the uuid and that uuid is not the package under test. The 1.4/1.7/1.8/1.9 variants still raised unconditionally whenever the uuid was present, so a package whose test/Manifest.toml dev's the package itself (path = "..") could not be activated on Julia <= 1.10. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #120 +/- ##
==========================================
+ Coverage 78.63% 81.69% +3.05%
==========================================
Files 34 34
Lines 941 945 +4
==========================================
+ Hits 740 772 +32
+ Misses 201 173 -28 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Can we add that reproducer as a test? |
Covers the reproducer from JuliaTesting#120: a package whose test/Manifest.toml dev's the package itself (what `julia --project=test -e 'using Pkg; Pkg.develop(path=".")'` produces) could not be activated on Julia 1.4-1.10 before the merge-project guard was ported. The new `test/sources/SelfDevTestManifest` fixture is copied to a temporary directory and both manifests are generated at test time, so the manifest format always matches the running Julia version. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
@oxinabox Done! |
|
|
||
| orig_project_toml_path = Base.active_project() | ||
| orig_load_path = copy(LOAD_PATH) | ||
| push!(LOAD_PATH, mktempdir()) # put something weird in LOAD_PATH for testing |
There was a problem hiding this comment.
This is the existing pattern from the other testsets in this file — it's on main in six other places (e.g. test/activate_set.jl:9, :39, :64). It puts an unrelated entry in LOAD_PATH so the test runs against a non-default LOAD_PATH, and the @test orig_load_path == LOAD_PATH in the finally block then checks that activation didn't disturb it. I just followed the surrounding convention here; happy to drop it from this testset if you'd rather, but that would make it the odd one out.
There was a problem hiding this comment.
hmm i wonder they i did that.
I suspect it was a particular bug.
2 participants
Summary
src/julia-1.11/activate_set.jl(and the 1.12/1.13 copies) guard the "can not merge projects" error when merging the test manifest into the package manifest:The
julia-1.4,julia-1.7,julia-1.8andjulia-1.9variants still use the unconditionalif haskey(working_manifest, uuid) pkgerror("can not merge projects") end. This PR ports the 1.11 guard to those four files verbatim (theprune_manifest(sandbox_manifest, [uuid])call is left as-is; theSet([uuid])signature is only 1.12+).julia-1.0..1.3do not have the merge loop and are untouched. Nothing else changes.Reproducer
A package with a
test/Project.tomlthat lists the package itself and atest/Manifest.tomlthat dev's it (whatjulia --project=test -e 'using Pkg; Pkg.develop(path=".")'inside the package produces):On Julia 1.10,
julia --project=. -e 'using TestEnv; TestEnv.activate()'fails withcan not merge projects, because the package's own uuid is already in the working manifest (it is the package under test) and the fixed subgraph copied from the test manifest contains it again. On Julia 1.11+ the same layout activates fine. With this change it also activates on 1.10 (verified with 1.10.12).This is the failure users of the VS Code extension's test item runner see on Julia <= 1.10, see julia-vscode/julia-vscode#3832 and julia-vscode/julia-vscode#3633.
Tests
Pkg.test()of this package on Julia 1.10.12: 18/18 pass.main.🤖 Generated with Claude Code