It is not clear to me how resolve is supposed to work.
Scenario:
I have a package A
it depends on package B
There is a new version of package B
In package A I increase the compat entry of package B to the new version.
I type Pkg.resolve(). It fails because the old version is still in the manifest.
Now I have to type
add PackageB@<newversion>
And all works fine.
Is this an intended behaviour? Wouldn’t it be more logical if:
either resolve just updates the manifest and succeeds
or at least prints a warning: Version x in in the manifest, version y in compat, please use Pkg.add to update to the new version
I am not 100% sure I understand the scenario you have or what “It fails” means.
I can only comment that every now and then I have a similar scenario (I think), but then I have both A and B from your description in development mode. In those the outdated manifest (I think) causes that resolve does indeed not work, since there are also no “versions to switch to” when both are in development mode. Pkg.update() helps in my scenario at least since it updates versions and resolves.
If this is not your scenario, maybe you could provide a bit more details?
Ok, I also keep my environments small, so for me updating them all is fine – but I can see the problem when this triggers too much recompilation.
The reason I mentioned development mode is, that I do not totally understand your scenario, and having two packages in development mode was the only scenario I ever encountered that. Maybe with source that is similar, sure.
(V3Kite) pkg> st
Project V3Kite v1.0.3
Status `~/repos/V3Kite/Project.toml`
[c59cac55] AtmosphericModels v0.3.7
[336ed68f] CSV v0.10.16
[a93c6f00] DataFrames v1.8.2
[c1363496] DiscretePIDs v1.0.0
[f67ccb44] HDF5 v0.17.3
[9de5dc81] KitePodModels v0.4.0
[90980105] KiteUtils v0.11.12 `~/repos/KiteUtils`
[b964fa9f] LaTeXStrings v1.4.0
⌅ [7771a370] ModelingToolkitBase v1.40.0
⌅ [d96e819e] Parameters v0.12.3
[aea7be01] PrecompileTools v1.3.4
[6038ab10] Rotations v1.7.1
[90137ffa] StaticArrays v1.9.18
[10745b16] Statistics v1.11.1
⌃ [9c9a347c] SymbolicAWEModels v0.11.1
[3a884ed6] UnPack v1.0.2
⌅ [ed3cd733] VortexStepMethod v3.3.6
[ddb6d928] YAML v0.4.16
[ade2ca70] Dates v1.11.0
[37e2e46d] LinearAlgebra v1.12.0
[de0858da] Printf v1.11.0
[3fa0cd96] REPL v1.11.0
[9e88b42a] Serialization v1.11.0
Info Packages marked with ⌃ and ⌅ have new versions available. Those with ⌃ may be upgradable, but those with ⌅ are restricted by compatibility constraints from upgrading. To see why use `status --outdated`
Warning The project dependencies or compat requirements have changed since the manifest was last resolved. It is recommended to `Pkg.resolve()` or consider `Pkg.update()` if necessary.
They tell me to use Pkg.resolve(), which fails.
up SymbolicAWEModels
results in
(V3Kite) pkg> up SymbolicAWEModels
Updating registry at `~/.julia/registries/General.toml`
ERROR: empty intersection between VortexStepMethod@3.3.6 and project compatibility 4
The next step also fails:
(V3Kite) pkg> up VortexStepMethod
Updating registry at `~/.julia/registries/General.toml`
ERROR: empty intersection between SymbolicAWEModels@0.11.1 and project compatibility 0.13
This works:
(V3Kite) pkg> up SymbolicAWEModels VortexStepMethod AtmosphericModels
But I still think resolve should determine which packages need updating to resolve the conflicts. Why do I have to do that manually?
And Pkg.update() updates all packages, which I don’t want. I have packages that need 3 minutes for pre-compilation, and I don’t want that to happen when it is not needed.
As far as I understand, resolve is deceptively modest, doesn’t appear to even update registries. I only really use it while changing dev-ed local dependencies. The line is blurry, but updating the minimal subset of add-ed dependencies until the environment works seems more appropriate as an option for update. When we do have packages to name, update has a few preserve options, and add has even more. I wouldn’t really know how, but maybe the API could be clearer and more intuitive.
To me the docs for resolve 13. API Reference · Pkg.jl are a but vague, but to me it seems, that resolve would never go as far as updating a package. And sure the docs should be improved by someone who has more knowledge here.
As far as I understand the current implementation and workflow, for the breaking version in B in order for A to “catch up” it has to update (beyond a breaking version that is) – and resolve is not enough.
I personally was fine with the update path until now – even the global one. AS I wrote, once you have figured out which packages, updating just those is available.
Yes, for me it easily takes a minute as well (the global one), but this scenario of breaking releases in dependent packages I develop / work with locally is also not happening that often.
If it never updates a package, what is it then good for in the first place? To resolve conflicts, you always have to either upgrade and/or downgrade packages.
For a more detailed answer on that, we have to wait for someone with more knowledge.
As far as I see, resolve probably can “bump” the version of B in a manifest, if it does not go beyond the [compat] in A, so in practice minor versions that are non-breaking. This might be handy, if C depends on a version in B v 0.2.3 but you have loaded only v0.2.2 or so. So maybe resolve can resolve non-breaking increases?
At last whenever I changed compat over a breaking version change – like in your scenario – I think I have to do update.
But again – I am not an expert, and the docs for resolve are a bit minimalistic.
