I think this has to be the case, unless you want to make the General registry a free-for all. I’ve already mentioned above how the automerge checks can be useful in preventing people from accidentally registering package, others have mentioned typo-squatting which is another good reason to have some basic checks.
Also I’m not sure that people have said package authors should do any of the things you list:
Please a naive similarity check: You absolutely don’t have to do this, packages get merged all the time with the name similarity is okay tag, there’s 230 packages like this listed [here]. What you should be doing in this case is just comment on the PR to General to say “I really think this name similarity is okay” and chances are people will agree with you (unless you are typo squatting)
Advocate for the package - not sure where you got the impression, but I don’t think anyone suggested that. I would think that someone who registers the package in General does so because they want others to use it (and maybe get additional benefits from this such as testing in the wild, feedback and suggestions, or maybe even contributors) and so they’d naturally be inclined to “advocate” for the package by e.g. doing an [ANN] thread on here, writing a captivating Readme on GitHub and/or nice docs and tutorials etc., but there’s absolutely no obligation on you to do this. Again looking at the new packages feed on GitHub I’ve usually never heard of any of the packages that get registered, and often looking at their GitHub doesn’t tell me a lot about what they do. [EDIT: I now see this was at the end of Matt’s post and he used “advocate” in quite a loose sense - like I said just posting on th PR saying “this name is good” usually suffices, sometimes combined with a reminder if people forget to merge the PR)]
Work on other packages: I guess that’s Ronny’s suggestion to join forces if the registration process brings up a closely related package. I think that’s sensible, but again it’s not something you should do to get your package registered, normally people would add a [noblock] comment saying “hey are you aware of package X which does something very similar” and then for the most part authors say “yes but it doesn’t really make sense to combine them” and the package gets merged. The friction introduced is pretty minimal, I’ve never seen a package not merged because a similar package existed. Also there are frequent complaints about package fragmentation in Julia so I think it’s a useful check on the off-chance that people are willing to contribute to an existing package they didn’t know about (which I think I’ve seen happen once).
These best practices though are suggestions which won’t stop automerge, and of course Genie and Makie are in the General registry. Again just looking at the list of “name similarity okay” merged packages above, in the last couple of months the packages Grumps, AutoGP, Tempo, and Wasabi were merged.
AutoGP is a good example of a package where the name really isn’t ideal for General (as it’s a non-descriptive name using a domain-specific acronym), but the author insisted and so it got merged.
As you say this is quite similar to point 1 - there are good reasons to not automatically merge packages with names very close to existing names in General, and the friction introduced is minimal. Again, you do not have to solve a problem here, just comment on the PR to say that you want it merged despite auto merge failing.
As for namespacing, there is already the possibility to have registries other than General, which I know the BioJulia folks used to do. I don’t know anything about the practicalities of this, but @kevbonham is already here and will know more - it looks like there are some downsides as BioJulia moved away from having their own registry.
I agree that namespaces for packages (e.g. prefixing org names) would be good to avoid conflicts, but in my opinion this should be accompanied by the possibility of aliasing packages at installation, in order to reduce the burden of dealing with package names elongated by their namespaces.
Currently packages can be aliased when imported, so that if org namespaces were supported we could do
julia> import OrgName/PackageName as PackageName
But it would be nicer if it this were possible:
(myenvironment)> add OrgName/PackageName as PackageName
so that in any code of that environment you’d only have to import PackageName or using PackageName.
Perhaps this might be feasible without breaking things, e.g. adding a section [alias] in Project.toml with the mappings of environment aliases to “real” package names, recognized by Pkg.status, using, import etc.
That way, if a great name is taken by an unmantained package in the available registries, in practice it could be reused by a more popular one - recommending the usage of that alias upon installation. Even more, aliasing with the “bare” name without namespace prefix could be the default behavior if that “bare” name is unique in the registries, or for the first package added to the environment with that name - assuming that in the majority of cases, one won’t need various packages registered with the same name in the same environment.
Registering the package anywhere, including General, isn’t related to it being open-source or useable at all! Publish it somewhere like github/gitlab/anything else, create an announcement topic here on discourse to get visibility - that’s it.
Well, this specific syntax would be breaking because there could be a package named as, but surely there might be other ways of accomplishing this (add PackageName=OrgName/PackageName, or something else).
While I agree that packages don’t have to be registered in General to be accessible as Open Source libraries, not being registered in General has a few severe limitations:
no search/suggestion for package name in Pkg
more difficult to add the package as one has to type the full Git(Hub) URL
others can’t register their own packages if they use your unregistered package as dependency (cause the bot does not know how to resolve the dependency)
It is indeed possible to create and use a package with a two-letter name. Whether a package called as would ever be accepted in the General registry is another story, of course - but it could still exist in another, or in one’s private registry.
@essenciary, what resolution are you looking for here? I think your points have largely been addressed: all the important decisions were made by the bot (we don’t know why a human stopped participating in the discussion, but there are many potential explanations which include being busy). Likewise, the bot explained the process and its reasoning, and even gave a 7-day warning. (Nice touch!) Finally, in any unregulated commons, what happens is the loggers come in and cut down all the trees for their own profit, so a little bit of red tape is necessary.
Is the one remaining question “will we get organization-level namespaces?” I think not anytime in the near future (someone would have to implement it, and that would likely be a Julia 1.11 feature at the earliest), so if your goal is to register your package you seem to have two options:
Lobby for the name you have chosen and resubmit the PR. Several mechanisms for this have been proposed.
Accept the advice that the name is a bit on the generic side, and try to come up with something more descriptive.
Just chiming in from the sidelines here, but I personally find it really hard to justify merging/releasing a package with only a single sentence in its README describing the use; how am I as a member of the community supposed to use the package, if noone is around to tell me how?
Since it wasn’t mentioned already, it’s worth noting that the aforementioned Slack thread also discussed how to improve on the status quo (which most agreed has some obvious deficiencies) for people hoping to register packages.
One thing that came up is the the bot admonition on the General registry PR is the first time a lot of folks actually encounter the guidelines. So one spends a decent amount of time coming up with a name, maybe writes a paper about the project and then hits a brick wall when it comes time to publish it in the registry. Some ideas proposed to address this:
Put documentation about the naming rules in an extremely visible place so that it’s almost impossible to miss. For example, a big banner near the top of How to develop a Julia package and making 5. Creating Packages · Pkg.jl more obvious instead of being just another block of text easily skipped during skimming because it’s near the bottom of a long docs page.
Provide info on naming much easier in the process using the existing automated tools. e.g. the Registrator bot could print them out before opening a PR on General. Ideally this could happen when installing the Registrator app, but I don’t know if that’s possible. Alternatively, GitHub - JuliaRegistries/Registrator.jl: Julia package registration bot could have a big, flashing “read this first” link to the guidelines in 1).
Provide some low-friction, easy to access service to check names against the existing registry. Yes there is an automated way to do this using Automatic merging guidelines · RegistryCI.jl, but how many people know to a) look at the RegistryCI docs, b) look at the very bottom of that page to learn about naming guidelines, and c) how to create temporary environments to run the example snippet? Having some easy way to do this with just the stdlib or a hosted web service could avoid many automerge-related complaints in the first place.
I gotta disagree pretty hard on this one: packages that are registered in General should have a minimum of functionality, including some documentation (in the README or with Documenter). We do not allow “placeholder” registrations, and the point of the registry is that the package should be useful for the wider community. A package without even a hint of documentation is not.
Yeah, @Ward9250 put a bunch of effort into that, including creating a registrator bot, etc. The reason we moved away from it was IIRC twofold:
She was the only person that knew how all of the infrastructure worked, and had a lot of other commitments too. When there were problems, we had to wait until she was available to fix them.
More importantly, it meant that anything that depended on any package that was only in the BioJulia registry could not be registered in the General registry.
Point 2 also caused a bunch of confusion because a number of packages had previously been in General, but the newer versions were only being posted to BioJulia, so people were installing old versions, or would try to register in general and have everything fail because only the old versions could be seen by people that added their package without also adding the BioJulia registry.
There were probably solutions to both of these problems, but there didn’t really seem to be much benefit of the separate registry (certainly no benefit that was worth the effort), so we went back to General.
I’m unsure if you’re speaking as a maintainer of the registry, but if this is required for the registry, it should be imposed in the automated checks. I am not certain how one establishes that documentation exists, as a GitHub readme may be incorrect or out-of-date at the time of registration, especially so in initial versions of a package. In any case, there are often packages that are not meant to be used directly by users, and a higher-level interface may be provided by a second package. In such cases, perhaps it’s imposing a rather high standard to expect the “Core” package to be well-documented, especially at the time of merging.
I don’t expect any immediate resolution or action - my preference is for a more robust system, long term. It’s not hard to foresee that finding good names will become harder and harder – all we have to do is look at other communities (.com domains, twitter handles, NPM, etc).
If there is no desire to improve the current system, I think it would be of high value to have something like GoLang has, and make Github repos first class citizens - this would allow packages to be registered in General while having unregistered dependencies on Github.
IMHO the system would work well if registration was automatically under the githubhuser/PackageName name, and if a higher bar was set for registering without a prefix (full docs, etc), if anyone wants that for some reason.
I perfectly understand that that would require someone implementing it. But it is not clear for me from this and other discussions that the core developers think this is a good idea at all. If we had at least a consensual feeling that this would be a good idea, we/someone could at least try to think on how to implement it.
