Adding "caps" (upper-bounded `[compat]` entries) to all packages in the General registry

Community
, , , ,
1

We have used the RetroCap.jl package to add “caps” (upper-bounded [compat] entries) to all packages in the General registry.

More specifically, for each package in the General registry, we iterate over each of the package’s registered versions. For each registered version of the package, we iterate over each of the package’s dependencies. For each dependency:

  • If the package does not have a [compat] entry for the dependency, then RetroCap adds an upper-bounded [compat] entry for the dependency.
  • If the package has a [compat] entry for the dependency but the [compat] entry is not upper-bounded, then RetroCap replaces the original [compat] entry with an upper-bounded [compat] entry for the dependency.

The upper bounds that we have added are “monotonic,” meaning that older releases have older dependencies.

In this context, “upper-bounded” means that the [compat] entry only allows a finite number of breaking releases.

These changes were made in this PR: https://github.com/JuliaRegistries/General/pull/11114

If these changes have broken anything, please open an issue on the General registry repo and CC:

  1. @DilumAluthge
  2. @KristofferC
  3. @maleadt

For posterity, the script used to generate these changes was:

julia> import Pkg
julia> Pkg.add("RetroCap")
julia> import RetroCap
julia> rm("General"; force = true, recursive = true)
julia> run(`git clone git@github.com:JuliaRegistries/General.git General`)
julia> cd("General")
julia> run(`git checkout master`)
julia> run(`git checkout -B YOUR-INITIALS/add-caps`)
julia> RetroCap.add_caps(RetroCap.MonotonicUpperBound(), RetroCap.CapLatestVersion(), pwd()) 
julia> run(`git add -A`)
julia> run(`git commit -m "Use RetroCap.jl to add monotonic \"caps\" (upper-bounded compat entries) to all packages"`)
7 Likes
2

Just to give some more details, this is a one-time thing to rectify the situation that a lot of old versions of packages had no compat bounds at all. So what could (and quite frequently did) happen was that the resolver (the algorithm in the package manager that figures out what versions to install) found a really old version that had no compat bounds, got happy because that version claimed to work perfectly in the current project (because of no compat bounds), and the resolver then installs that many-year-old version and people get confused why things are not working.

Now, those old versions have compat bounds and should no longer be picked by the resolver.

14 Likes