how to safely rename an unreleased golang libray repo

[plastikfan]

Select Topic Area

Question

Body

I know the basic operation of renaming a repo on Github by going to the project settings. My query is specifically about golang library modules. I am asking this to try and avoid any unforseen catastrophes I might not be aware of. The reason for my concern is the 'unique' way that Go lang modules uses a url as part of the identity of a repo that is not present in other eco systems; ie the mod file.

Since my library is not released yet, I do not have to worry about affecting downstream users (otherwise I would not even consider doing a rename) and because of this I do actually think there will be no problem, but I would prefer to be safe than sorry. Thanks.

[vipinAlways]

😊

[plastikfan]

thanks @manqur that sounds great. I haven't had a chance to do the rename yet but I'll follow these instructions first on a test repo, then on my target repo. These steps look to be the intuitive ones I would have done anyway, but good to know that there doesn't yet appear to be anything I havent already thought of.

[plastikfan]

@manqur where has your comment gone? I am in the process of doing the rename and I wanted to refer to your checklist which has now disappeared. Why?

[plastikfan]

Ok, once again @manqur your comments have disappeared mysteriously after being being restored for a short while. My workflow for this scenario was sligtly complicated by the fact that I also wanted to make sure that my coverage setup on coveralls was maiintained after the rename. Just to re-iterate, I was able to rename in this fashion because my package was unreleased and therefore did not have to worry about the potential for breaking downstream clients; do not do this if this is not the case for you. Also, try this out on a test repo first so you have gained some experience. Also, this assume the pull request model for accepting changes to the repo.

These are the steps a ended up following (rename traverse to agenor):

✨ on a new branch:

• change mod file entry
  -> rename traverse to agenor

• change import links (textual search and replace):
  -> rename "snivilised/traverse" to "snivilised/agenor"

• change package declarations (textual search and replace):
  -> change "package traverse" to "package agenor"
  -> change "package traverse_test" to "package agenor_test"

⚠️ Ordinarily, I would loved to have been able to use the refactor feature, by highlightlighting "traverse" in a package statement (ie "package traverse"), but when I did so, an error was reported that prevented me from doing so. The issue may have been specific to this repo, so anyone else reading this, should always to change package namaes via an F2 refactor rename as this will make your life so much easier.

• change package references (textual search and replace)
  -> change "traverse." to "agenor."

• change other refs (textual search and replace)
  -> change "traverse"/"Traverse" to "agenor"/"Agenor"

• change aliases

• -> change "tv." to "age."

• Disable the Continuos Integration workflow on GitHub

• push changes

• rename the repo in the github repo settings

• go to repo settings on coveralls, then hit resync. This will show the new name agenor

• re-enable Continuous Integration workflow

• implemente the pull requiest by merging back to main

• perform another update to the repo, see the workflow run and update coverage on coveralls. The coveralls history will be retained.

NB: in this sceanrio, it's not neccesary to perform a clean of of the local go package cache (go clean -modcache) as no other package was a client of the package in its old name.

So in summary, the risk factors of renaming a golang library package turned out not to be significant. In fact the biggest risk item in acheiving this was making sure that coveralls coverage history is maintained and this is not specific to golang, no special action is required on coveralls, other than to perform a refresh. As long a you dont have downstream clients, renaming a Go module should be a fairly trivial task.