Don't rewrite Project.toml on resolve/instantiate

[PatrickHaecker]

Project.toml is a file edited by the user and Manifest.toml is the derived output, but resolve/instantiate shared the write_env path with add/rm and could rewrite Project.toml as a side effect of producing the manifest. With a top-level workspace [sources] entry this normalized the source path and dropped comments and formatting.

Producing the manifest should never edit the project, and the project serializer is lossy, so the rewrite is destructive rather than just noisy. This bug kind of kills the reproducibility story: When you check out a repo with a Manifest.toml and a Project.toml and you instantiate it, you really don't want changes to your source tree!

Make resolve default to skip_writing_project=true, and have instantiate pass it in both of its up fallbacks (missing manifest and update_on_mismatch); the normal instantiate path never wrote the project. Add a workspace regression test and a CHANGELOG entry.

Claude Opus 4.8 supported in creating this PR

[PatrickHaecker]

@KristofferC: Could you please review this?
This is some change in behavior, but I think it is exactly in line with your view of Project.toml being the source and Manifest.toml being the derived file.
This is also necessary to fix JuliaC to work correctly with workspaces.

[PatrickHaecker]

This should probably be backported to 1.13.

[topolarity]

This change seems reasonable to me, but I am confused: Is there any reason to set skip_writing_project = true?

Does resolve ever meaningfully modify the Project.toml part of the environment, or is it just re-written to "canonicalize" the file (deps ordering, etc.)?

[KristofferC]

That kwarg seems to have originated from #2541. Not sure what it does.CI failures might explain something of it?

[PatrickHaecker]

You want to set skip_writing_project = true to get a reproducible build in a workspace and to keep Pkg's (virtual) hands off of your potentially manually edited Project.toml .

skip_writing_project = false is good if you want alphabetically sorted entries, normalized paths, consistent formatting and removal of any comments (but only happens if your Project.toml would actually change).
I think as long as we make sure that Pkg does the "canonicalize" when the user clearly wants to modify Project.toml (Pkg.add and the like), I think there is a story to make the skip_writing_project = true behavior the default, remove the keyword argument and potentially offer a separate "canonicalize" functionality which reliably does the job when you call it (and does not depend on whether there were modifying side effects or not).

Update: I am not sure whether skip_writing_project is part of public API. Documentation does not mention it, but it is listed as a method of the public function Pkg.resolve in Julia 1.12:

julia> Pkg.resolve |> methods
# 2 methods for generic function "resolve" from Pkg.API:
 [1] resolve(; io, kwargs...)
     @ ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/Pkg/src/API.jl:454
 [2] resolve(ctx::Pkg.Types.Context; skip_writing_project, kwargs...)
     @ ~/.julia/juliaup/julia-1.12.6+0.x64.linux.gnu/share/julia/stdlib/v1.12/Pkg/src/API.jl:455

[PatrickHaecker]

@KristofferC, @topolarity: So what do you propose?

• merge as is and potentially remove skip_writing_project in a follow-up PR?
• remove skip_writing_project now, because you decide that this is not public API, and merge afterwards?

Having this PR merged would help correctly supporting workspaces in JuliaC.

[topolarity]

I think I agree with the argument and I'm generally in support - What's the cause of the CI failures though?

[DilumAluthge]

@PatrickHaecker Can you update the master branch in your fork? It looks like it's behind a few commits.

[PatrickHaecker]

@PatrickHaecker Can you update the master branch in your fork? It looks like it's behind a few commits.

Thanks, @DilumAluthge. Seems to have been a VS Code Git problem: Fetching from upstream did not show any changes, but pulling updated now anyway)

[DilumAluthge]

Thanks!

[PatrickHaecker]

I think I agree with the argument and I'm generally in support - What's the cause of the CI failures though?

Thanks for the hint. I was to much in "contribute to a package" mode and ignored issues, because they were only in nightly, which (in retrospect) obviously are the only useful tests for Pkg.

There is one test which previously tested the implicit rewrite of Project.toml. Due to the "do not rewrite per default policy" of this PR, I changed this to now explicitly request to rewrite the file.

The other test should be fixed by rebasing on recent master. So testing should (hopefully) be green.

[PatrickHaecker]

The windows test error is a disk space problem on the CI runner. So tests look good.