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:
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:
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.
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.
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…