How to resolve Go module declares its path as "x" but was required as "y" between 2 versions

kaizenCoder 0
Viewed 42

I recently had to move private repositories from SaaS Gitlab to an on-premise version. Everything was going well where I did:

  1. Update old go module paths in repo a from old.com/workspace/a to new.com/workspace/a
  2. Add a new tag v1.2.3-new to the latest commit
  3. Update repo b to reference latest tag v1.2.3-new from new.com/workspace/a
  4. Run go mod tidy in repo b and verify it works

Now I have a requirement to reference an older version tag of new.com/workspace/a (originally old.com/workspace/a). So in repo a, I checked out the older tag, fixed up the module path to new.com/workspace/a from old.com/workspace/a and tagged it as v1.1.1-new.

In repo b then I referenced new.com/workspace/a with v1.1.1-new. However, this results in:

go: new.com/workspace/a@v1.1.1-new: parsing go.mod:
    module declares its path as: old.com/workspace/b
            but was required as: new.com/workspace/b

If I check the v1.1.1-new tag in repo a, the module path is set correctly in the go.modfile:

module new.com/workspace/a

It is unclear to me why it works with the tag v1.2.3-new on the latest commit but fails when I reference an older commit.

go-modules go
1 Answers

So I can't say I fully understood why this worked but here are the steps that made it work (including what didn't).

  1. I resorted to clearing the cache with go clean -modcache

  2. Tested with the following but it still failed.

    go get new.com/workspace/a@v1.1.1-new

  3. As per my comment in the original question, this worked via the v1.1.1-new commit hash So I resorted to that again.

    go get  new.com/workspace/a@27ca81f7

    Now it picked up the version for that commit and was successful. The go.mod file was also correctly updated with the tag/version despite using the commit hash in the go get command.

    new.com/workspace/a v1.1.1-new
kaizenCoder0
Related