I believe that I've identified a bug in Registrator.jl that is now causing problems when trying to change a package URL. The purpose of opening this issue is three-fold:
- Figure out how to help the package author in this specific situation.
- Diagnose and fix the bug in Registrator.jl.
- Add checks to AutoMerge to catch this kind of issue in the future.
The specific situation here concerns the SimSpread.jl package (located in the registry at S/SimSpread).
The SimSpread package was originally registered in October 2023; here is the new package PR: #94323
Look at the diff for #94323: https://github.com/JuliaRegistries/General/pull/94323/files
Specifically, look at the diff for S/SimSpread/Versions.toml file:
Somehow, Registrator.jl put two versions (1.0.2 and 1.0.3) into #94323. This (to me) seems like a clear bug. A single PR should only register a single version; this should hold true whether the PR is a new package PR or a new version PR.
Currently AutoMerge is not set up to detect this kind of situation; AutoMerge assumes that Registrator.jl generates PRs in certain ways, with "one version per PR" being one of those assumptions. So on https://github.com/JuliaRegistries/General/pull/94323, I'm guessing that AutoMerge only ran its checks on 1.0.3, and AFAICT (from the AutoMerge comment) those checks passed, and the PR was AutoMerged.
Unfortunately, 1.0.2 was never checked by AutoMerge. And, per the author (see https://github.com/JuliaRegistries/General/pull/145696#issuecomment-3774666032), there is no commit in the repo that corresponds to 1.0.2.
The author is now transferring the repo to an org (#145696), and the Treecheck is failing, because the "new repo" doesn't contain the tree for 1.0.2.
Some questions:
- What do we do in the specific situation? Do we delete 1.0.2 from the registry? Historically, we never delete registered versions, except in very rare situations. However, this might be one of those very exceptional situations. It's not even clear to me if 1.0.2 has ever been installable.
- Where is the bug in Registrator.jl, and how do we fix it?
- What kind of checks can we add to AutoMerge to detect this kind of issue before merging?
Activity
3
GunnarFarneback9mo ago- No idea how this happened. The only way to get two versions via RegistryTools is to run it twice on the same copy of the registry files. But Registrator creates a new branch when the version is changed. If there is a bug it must be related to how Registrator manages the registry files between invocations.
- Check that a new package has exactly one entry in
Versions.toml.
GunnarFarneback9mo ago- More ambitious alternative: Let AutoMerge extract relevant metadata from the PR text, then call RegistryTools itself and see whether the changes match the PR. Main problem is that it requires some synchronization of RegistryTools updates between AutoMerge and Registrator.
This is a wild case.
I strongly suspect that 28da8c8721266b5dfba926a66f609b8fb9337940 did exist at some point but got lost after a force push.
It should be possible to add back the tree hash to the repository since the tree can be downloaded by Julia, but on the other hand it's of limited value since it can't be loaded anyway.
It is indeed trying to do
using Randomdespite not havingRandomas a dependency inProject.toml.I think this is a case where it's warranted to remove a version from the registry. It shouldn't have been there in the first place and nobody can possibly have used it successfully.