I want to highlight a recent experience regarding this subject and offer some criticism and suggestions in the spirit of improving the Julia ecosystem.
A few days ago I registered a new websocket (generic tech term) library, calling it Websocket. This was automerged into the General Registry after the 3 day wait for new packages.
I was subsequently asked by a registry moderator to rename this package because of potential confusion with the pre-existing WebSockets package. Fair enough, but this brings me to:
I chose the new name SimpleWebsockets for my package, created a new Github Repo, updated tests, documentation and CI pipelines and re-registered under the new name. The mods were helpful in getting this merged without the 3 day wait, and it got included into the General Registry
I was however unable to solicit clear guidance on how to effectively deprecate the old package . Upon trying to merge a deprecation notice into the old Websocket package, it became clear to me that Websocket has been deleted from the General Registry. Again, fair enough, but brings me to:
Criticism
WebSockets, Websocket and SimpleWebsockets are now ALL listed on JuliaHub.
Pkg.add(“Websocket”) fails without useful information about the alternative.
compathelper will give no future advice to users who may already have installed Websocket
Given that the original purpose of renaming the package was to avoid confusion, I feel that the process has had the opposite outcome, and sowed the seeds for more confusion. This brings me to:
Suggestion 2
That Juliahub does not list packages that have been removed from General Registry
That there is a Deprecated Registry where packages go to die, but reserve the UID and name in the ecosystem.
That Pkg.add will give a deprecation notice and helpful alternative suggestion if a user tries to add a deprecated package.
That compathelper will notify users as and when a dependency becomes deprecated.
That a well defined procedure for package deprecation is agreed and documented.
That doesn’t address the guidelines in the Pkg docs though, do you think it would be valuable to also have advise there to choose a name sufficiently different from existing names?
Yes, personally I think this is a better approach than enforcing it through code. In my scenario, I had read the naming guidelines before starting work on my package. If it was made clear there as a community standard, I would have named my package differently from the outset avoiding the confusion and saving myself an afternoons retrospective work.
Ok, that makes sense. If you or anyone else wants to give improving the naming guidelines a try, the place to do it is here: https://github.com/JuliaLang/Pkg.jl/blob/master/docs/src/creating-packages.md. (And for anyone who isn’t familiar with GitHub, it’s very easy to do; just click the pencil in the top right of that page, make your changes, and then click propose changes, and then create pull request).
enforcing it through code
FYI the automerge guidelines are only guidelines, and are not enforced as rules. They are chosen to be conservative so that automatically merged packages should be “definitely fine”, but not meeting them doesn’t mean the package cannot be merged (manually). I only bring this up because they are commonly misinterpreted as hard rules; I do get your point that it would be nicer to know about this kind of thing well in advance rather than at registration time.
Yeah, unfortunately, Juliahub’s indexing code cannot handle deletions yet. This was an edge case that hadn’t been considered. We’ll have to delete this from various indexes and databases now manually, so I’ll ask for your patience, sorry.
I don’t believe that it is yet well defined, and I am open to correction on that.
Seems that the good norm is that once a package has an ID and name, it should never be removed to avoid seven circles of ecosytem repository hell.
In my particular instance that prompted this post, my package WAS deleted, but the chaos has now been manually stopped before it reaches further down.
My suggestions at the top of this post may be simplistic, but I feel that it should be feasible to providing some way not to DELETE a package, but tag it as deprecated which hides it from Juliahub and invokes helpful messaging from Pkg and compathelper.
edit:
Maybe Juliahub could also have some “name-checker” function to test if a name is available and suitable before a package creator starts works.
Yeah, I just think it would be a pity to not be able to free up good package names when they have been deprecated for some period of time. I only have 1 package in the registry but it’s kind of a crappy package to be honest and I’ve thought about removing it and I’d hate for someone else to not be able to create a package with the same name if I can’t remove it. I suppose I could always just make them an owner/maintainer of the GitHub repo but what if a repo owner isn’t responsive?
Somebody creates package BandTupintheair, which is rubbish. A few people use it as dependencies regardless.
It gets deleted, and a new package with the same name is created. The users of the original package update to the new version and things go horribly wrong. They are now unable to roll back to the previous version and the world is seriously broken…
