Improve the implementation of force_latest_compatible_version
#2541
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request improves the behavior of the following two keyword arguments to the
Pkg.test
function:force_latest_compatible_version::Bool
allow_earlier_backwards_compatible_versions::Bool
These two keyword arguments are:
force_latest_compatible_version
input, and add the "auto-detect Dependabot/CompatHelper" functionality julia-actions/julia-runtest#20 and Meta-issue: deploy theforce_latest_compatible_version
fix to the most common CI providers JuliaRegistries/CompatHelper.jl#298)Before this PR
Here is the current behavior:
Pkg.test
creates the temporary sandbox environment.Pkg.test
runs the resolver.[compat]
entry and check that the direct dependency is at its latest compatible version. If at least one direct dependency is not at its latest compatible version, we throw an error. (For a direct dependency that does not have a[compat]
entry, we print a warning and do nothing.)Pkg.test
runs thetest/runtests.jl
file.This implementation works pretty well, but it does have some flaws:
Pkg.test
was not able to use the latest compatible version of the dependency. The user will need to clone the repo and run e.g.] add [email protected]
locally in order to figure out why the dependency is being held back.Manifest.toml
file into source control, and if the manifest file uses an older version of the dependency, and ifPkg.test
is able to use the exact same versions as the manifest file, thenPkg.test
will use the older version of the dependency, and thus the error will be thrown.After this PR
This PR changes the implementation as follows:
Pkg.test
creates the temporary sandbox environment.[compat]
entry, we modify the[compat]
entry so that it only includes the latest registered version of the dependency that is compatible with the original[compat]
entry. If a direct dependency does not have a[compat]
entry, we print a warning and do nothing.Pkg.test
runs the resolver. At this point, if the resolver is not able to use the latest compatible version of all dependencies, it throws aResolveError
.[compat]
entries back to their original values.Pkg.test
runs thetest/runtests.jl
file.Here is an example to illustrate step 2. Suppose that your package has a direct dependency on
Foo.jl
. And suppose thatFoo
has the following registered versions:0.1.0
0.1.1
0.2.0
0.2.1
Suppose that currently, your package has a
[compat]
entry that looks like this:And suppose that a bot (e.g. CompatHelper or Dependabot) opens a PR to change your package's
[compat]
entry to this:During step 2, we (roughly speaking) modify the
[compat]
entry to look like this:This ensures that the resolver uses
Foo
version0.2.x
.This new implementation solves the previously mentioned flaws:
Pkg.test
will use the latest compatible version of each dependency, even if there is aManifest.toml
file that uses an older version of a dependency.