Further compile failures due repository rename

[maxb]

Hello,

Sorry to be the bearer of bad news - there are still unsolved problems with the repository rename.

Specifically the issue is that currently, GitHub's automatic HTTP redirection from nats-io/go-nats to nats-io/nats.go is being relied upon to make old code - including old tagged versions of code which cannot be realistically updated - continue to compile.

This worked before Go modules came along, but now that there is a go.mod in the repository, module-aware Go will follow the redirect, but then realise that what it has downloaded declares itself (in go.mod) as being a different import path to what it was trying to fetch.

To reproduce this failure, the conditions are:

1. You are using Go in module mode
2. You are trying to compile something that depends on a library, which depends in turn on nats-io/go-nats

Here is a simple example where the intermediate library is github.com/go-kit/kit, which seems to show up a fair bit in various dependency trees:

$ mkdir sandbox
$ cd sandbox
$ go mod init sandbox
$ go get github.com/go-kit/kit/transport/nats@v0.8.0
go: finding github.com/go-kit/kit/transport/nats v0.8.0
go: finding github.com/go-kit/kit/transport v0.8.0
go: github.com/nats-io/go-nats@v1.8.1: parsing go.mod: unexpected module path "github.com/nats-io/nats.go"
go: error loading module requirements

You might suggest updating the code of go-kit, or using go.mod replace statements ... and whilst these are viable workarounds for fresh development, they don't address repairing the build of old tagged releases which would have previously built, so I propose a more thorough fix would be desirable - my suggestion is:

1. Create a new Git repository at the old URL https://github.com/nats-io/go-nats
2. Push into this repository the last commit on master before go.mod was added, and only the tags reachable from this commit - i.e.:

git push --follow-tags https://github.com/nats-io/go-nats d15e1944e18167d8e4266e8fe5371171af758c68:refs/heads/master tag v1.2.2 tag v1.3.0 tag v1.4.0

(Git's --follow-tags only follows annotated tags, so since three versions were tagged with lightweight tags they had to be mentioned explicitly.)

This should repair the existing builds, and the extra Git repository can then be archived and configured with a description explaining that it is just for compatibility and pointing users to the current repository.

Does this sound like a good approach?

[ripienaar]

I agree. Old repos should have been left alone and even archived with new ones made on new names. This is the only way to keep things working with how go is.

[derekcollison]

Will look into it this today. Apologies for the inconveniences.

[wallyqs]

Thanks @maxb for sharing this idea and again sorry for the inconvenience. I did send an update for go-kit/kit a couple of days ago but as you mention this would only work for builds using the next tagged release from that project.

[wallyqs]

@derekcollison following what @maxb suggests repo would look as follows: https://github.com/wallyqs/go-nats-follow

This is what I did:

# Create new repository and fetch tags from nats-io/nats.go
mkdir -p src/github.com/nats-io/go-nats
git init
git remote add nats-io https://github.com/nats-io/nats.go
git fetch nats-io
git remote rm nats-io

# Remove tags that use Go modules and nats-io/nats.go import path
git tag -d v1.8.0
git tag -d v1.8.1

# Set master to the last commit that does not use go modules
git remote add wallyqs https://github.com/wallyqs/go-nats-follow 
git push --follow-tags https://github.com/wallyqs/go-nats-follow d15e1944e18167d8e4266e8fe5371171af758c68:refs/heads/master tag v1.2.2 tag v1.3.0 tag v1.4.0

As a next step, we would create a repository at github.com/nats-io/go-nats and push the commits before introducing modules there. We could do something similar for go-nats-streaming as well.

[derekcollison]

I think it will work just as he described. I will give it a shot now.

[derekcollison]

ok this is in place and I verified it worked with the sandbox example above. Will update README.

[derekcollison]

@maxb Thank you very much for the suggestion. Much appreciated.

[maxb]

Thank you very much for this speedy fix! Looks good to me.

[derekcollison]

We also did this for the go-nats-streaming client as well. @ripienaar let us know if this helps and if you still have outstanding issues. And again, apologies.

[dancompton]

I really appreciate you all taking the time to do this on the weekend! I'll be checking bazel compatibility later today, but in theory this will fix the issue.

[derekcollison]

Thank you for the patience.