Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[workspace] Preserve top level dependencies better #3890

Open
fredrikekre opened this issue May 3, 2024 · 6 comments
Open

[workspace] Preserve top level dependencies better #3890

fredrikekre opened this issue May 3, 2024 · 6 comments

Comments

@fredrikekre
Copy link
Member

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
Copy link
Member Author

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
Copy link
Sponsor Member

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
Copy link
Member Author

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
Copy link
Sponsor Member

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
Copy link
Member Author

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
Copy link
Sponsor Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants