This article refers to problems that would probably only be seen for those running older versions of GO. If you know all about module management and are running up to date versions of GO with modules then you probably won’t find anything useful here. Up until very recently I was running a pre-module GO version and that bit me. If like me, you haven’t made the switch to modules and some of your dependencies appear to be missing functionality that you’re sure is there, read on.
Signs of Trouble
It all started with a fairly innocuous error message from the compiler that a particular structure I was trying to use from the AWS Kinesis video SDK was ‘not declared by package‘. The issue was pretty simple, a new function had been added to the package but locally the GO compiler didn’t think it existed. After doing the usual things like reading the docs and checking the source repo to make sure I had the name right it became an actual mystery. After way too much time messing around with other possible solutions I finally thought to check my local copy of the code and sure enough, the structure was not in the local copy of the SDK in ${GOWORK}/src/github.com/.... (Seriously, when will I learn to just go read the code first instead of wasting hours on wild theories about what could be going wrong, when in fact, what it said was simply literally true.) In fact, the local copy had hardly any of the expected functionality in it, clearly just an out of date copy locally then? Just a go get -u should resolve it. That did nothing because…
Turbulence Ahead
Some time in the past year or so AWS took the entirely reasonable step of changing the branch name in all of their repos from master to main. Unfortunately the old GO version that I was using was checking master and no amount of StackOverflow searching turned up a good approach for changing the default branch. There was a hint that it was possible to append the branch name to the name using an @ symbol but it only worked for modules. Since I’d been planning to update GO for a while I figured this problem was a good opportunity to make the update. The version I updated to, 1.16.3, made modules the default dependency management system. The good news is that the master/main problem went away immediately. The slightly less good news is that it worked by doing a go mod init in each affected module.
There’s lot of other good resources out there on migrating to modules, so you should read those if you’re looking for guidance on how to handle the migration. The key take away from this post is that sticking with old style language features for too long is bad and will bite you in unexpected ways. My bad. I don’t believe that fighting an issue like the reliance on master is worth the time, biting the bullet and moving to modules was a better time investment as it is supported going forward. It was a fairly major set of build changes for me and has taken a while to get back to a stable workable build so do allocate some time for yourself if you’re going to make the change.