Prefer adding already loaded dep versions

[IanButterworth]

Here JSON v1.3.0 exists. In the 2nd env Pkg.add prefers adding the versions that are already loaded so the env graph can be used in the current session without more precompilation.

Note that it's a preference via a high weighting in the resolver, not a hard rule.. so it shouldn't introduce resolver errors.

Developed with Codex and Claude

[KristofferC]

I'm not sure something like this should be on by default. I think it can get quite confusing if Pkg behaves differently depending on stateful things like what stuff you happen to have loaded.

[IanButterworth]

I agree that it changes behavior in a potentially confusing way but it adds a message when it does, and status will show when packages are outdated. Seems worth it for avoiding all the confusing reprecompilation

[IanButterworth]

This has a design issue that I've not yet been able to fix.. it's pinning the direct dep, rather than preferring it, like it does for the indirect deps.

[KristofferC]

Seems worth it for avoiding all the confusing reprecompilation

An alternative could be to have precompilation take into account currently loaded versions, or?

[IanButterworth]

I prefer this approach because it does more to respect semver. Loaded package versions could be incompatible (compat, semver etc.) with the versions being added in the env. Hiding that issue further is a worse option, I think.

[IanButterworth]

@StefanKarpinski is Resolver.jl likely to land in Pkg soon? I ask because I wonder if this will be easier to do with that? The current resolver does ok with the indirect deps, but I'm having a real headache allowing the resolver the flexibility to prefer the loaded version of the main dep being added, not have it pinned as the only option.

[PatrickHaecker]

This is a very interesting feature and surely useful in some situations. However, I have doubts, too, that it should be active by default.

The way I understand it, you add a package and you can get an older version than what your packages of your environment are compatible with because you have some old package loaded.

Yes, it's indicated, that a new version is available, but that's easy to miss. And sure, you save same compilation time, but in the worst case you lose much more time by debugging an error which is long fixed in a more recent version of the package.

Won't that lead to the recommendation that you should always restart your Julia process before you add a package when you want to be up-to-date? Is that what we want to advocate?

[Krastanov]

The vast majority of current questions I get from students confused about Pkg and "why is julia so slow and bloated" would be solved by this PR.

I think it is fantastic and much more understandable that add and up will become much more distinct after this RP. If anything, I would argue that this should have been the natural default from the very beginning: add should add packages consistent with the current environment, and only up should do the much more dangerous (and slow) operation of updating to newer versions.

[IanButterworth]

add should add packages consistent with the current environment

Specifically speaking these are deps that aren't in the current environment but are in the current session (where they are unchangeable because they are loaded). add already adds packages that are consistent with the current environment (where possible, via the tiered resolver)