JuliaLang / Pkg.jl

Pkg - Package manager for the Julia programming language
https://pkgdocs.julialang.org
Other
609 stars 251 forks source link

[workspace] Preserve top level dependencies better #3890

Open fredrikekre opened 2 months ago

fredrikekre commented 2 months ago

When adding package that is already in the manifest because of a top level dependency of a different project (or as a transient dependency, but those almost always track the registry) we should try to preserve the version. For example:

$ tree .
.
├── Manifest.toml
├── Project.toml
└── test
    └── Project.toml

$ cat Project.toml
[deps]
Example = "7876af07-990d-54b4-ab0e-23690620f79a"

[workspace]
projects = ["test"]

$ julia -e 'using Pkg; Pkg.status()'
Status `/tmp/tmp.C9bJWtPVPR/Project.toml`
  [7876af07] Example v0.5.4 `https://github.com/JuliaLang/Example.jl.git#master`

$ julia --project=test -e 'using Pkg; Pkg.status()'
Status `/tmp/tmp.C9bJWtPVPR/test/Project.toml` (empty project)

$ julia --project=test -e 'using Pkg; Pkg.add("Example")'
   Resolving package versions...
    Updating `/tmp/tmp.C9bJWtPVPR/test/Project.toml`
  [7876af07] + Example v0.5.3
    Updating `/tmp/tmp.C9bJWtPVPR/Manifest.toml`
  [7876af07] + Example v0.5.3

$ julia -e 'using Pkg; Pkg.status()'
Status `/tmp/tmp.C9bJWtPVPR/Project.toml`
  [7876af07] Example v0.5.3

I think this would be fixed by pinning top level dependencies of all projects in the first stage of the tiered resolver.

fredrikekre commented 2 months ago

PRESERVE_ALL should probably consider the full manifest (not just the subgraph for the project) then? And then perhaps there should be a PRESERVE_WORKSPACE_DIRECT before PRESERVE_DIRECT that preserve all top level deps in all workspace projects.

KristofferC commented 1 month ago

PRESERVE_ALL should probably consider the full manifest (not just the subgraph for the project) then?

I think this is already true. The behavior here is identical to when not using a workspace.

fredrikekre commented 1 month ago

Yea, I thought that adding a package that was in the manifest already was more of a no-op like rm is.

Perhaps add of a package that is already in the manifest should just not resolve at all like rm? Wouldn't result in precompilation at least which would be pretty nice.

KristofferC commented 1 month ago

Currently add Package is kind of used as a combined free + add in case the package is added by URL or devved. A bit convenient at times but perhaps not worth it.

fredrikekre commented 1 month ago

Yea, but add Package could also be thought of as "any version of Package". If you require a specific one you add Package@..., put in [compat] or add by url I guess?

KristofferC commented 1 month ago

Yes, I don't think people would complain about that behavior.