I’m pleased to announce that we are rolling out the first iteration of automatic merging for the General registry.
In order for your pull request to be automerged, it needs to meet the automerge guidelines:
New packages
Normal capitalization
name should match r"^[A-Z]\w*[a-z][0-9]?$"
i.e. starts with a capital letter, ASCII alphanumerics only, ends in lowercase
Not too short
at least five letters
you can register names shorter than this, but doing so requires someone to approve
Standard initial version number
one of 0.0.1, 0.1.0, 1.0.0
Repo URL ends with /$name.jl.git where name is the package name
Compat for all dependencies
all [deps] should also have [compat] entries (and Julia itself)
all [compat] entries should have upper bounds
Package can be installed
given the proposed changes to the registry, can we resolve and install the package?
Package can be loaded
once it’s been installed, can we load the code?
New versions of existing packages
Sequential version number
if the last version was 1.2.3 then the next can be 1.2.4, 1.3.0 or 2.0.0
Compat for all dependencies
all [deps] should also have [compat] entries (and Julia itself)
all [compat] entries should have upper bounds
Version can be installed
given the proposed changes to the registry, can we resolve and install the new version of the package?
Version can be loaded
once it’s been installed, can we load the code?
Important note
These guidelines are intended not as requirements for packages but as very conservative guidelines, which, if your new package or new version of a package meets them, it may be automatically merged.
Also, please note that commenting on a pull request will automatically disable automerging on that pull request. Therefore, if you want to leave a comment on a pull request but you still want that pull request to be automerged, please include the text [noblock] in your comment.
Can you either give an example of how to write the compat statements or point to it somewhere in the docs? I’m very interested in having this autonomy!
Great, for registrations currently in the backlog, should we bump them to trigger zeptodoctor or is it best to just wait for a kind human registrator to merge them?
You can retrigger if you want but I will go through the backlog manually later.
Yes.
The regular CI run approves the PR and then a cronjob merges. I set it to run every hour for now since the influx of PRs that meet the requirements is at the moment very low.
We’ll be implementing this: https://github.com/JuliaLang/Pkg.jl/issues/931. That’s also part of why there’s a three day waiting period. But adding a check that the edit distance to other package names is not too small is a good idea. Issue opened:
stdlibs are decoupled from julia distribution, and
the packages start lower-bounding stdlib?
In this scenario, IIUC, older packages without stdlib bounds can be chosen by the dependency resolver. Not that this is the worst problem, since there are so many packages without upper bounds. But my impression was that start requiring upper bounds was for avoiding this kind of situation and making Julia ecosystem more robust.
BTW, it took me for a while to realize that this is the case. I think it might be very surprising for people coming from other language ecosystems. It would be nice to document it somewhere. Maybe Pkg.jl documentation? But it’s not strictly about Pkg.jl and presumably, each registry can have a different policy for this.
I’m also a bit worried about this flexibility. It would mean that Manifest.toml generated at some point in time can become “invalid” in the sense it becomes impossible for Pkg.jl to generate the same Manifest.toml (even when there is no new versions are released). Can we get around this by enforcing some kind of monotonicity in the compat bounds change in JuliaRegistries/General (e.g., only increasing bounds is allowed)? Another worry is that this probably is not going scale once JuliaRegistries/General becomes (say) as big as PyPI.
@StefanKarpinski I noted a few potential issues in last comments, but assuming that you are referring to:
I think this would also mean that, a Project.toml with some “tight” [compat] that is Pkg.instantiateable at some points in time may not be so at other points in time. I find it contradictory to the emphasis on immutable aspects in the rest of Pkg.jl. Also, I suppose it means that Pkg.resolve is not an idempotent operation? I think is a reasonable assumption one can make, even though it’s not documented to be so.
Maybe it’s OK since full reproducibility still requires Manifest.toml anyway. But, if JuliaRegistries/General “officially” allows tweaking version bounds, I think it’s nice to document these properties.
