go get results in 410 Gone

[torbjornvatn]

#162 What version of the package or command are you using?
v3.1.1

What are you trying to do?

I'm trying to upgrade to v3.2.0 using go get -u github.com/mholt/archiver

What steps did you take?

First I ran go get -u github.com/mholt/archiver but it didn't find the newest version. The I tried to manually change the version to v3.2.0 in the go.mod file, but then it fails with an error instead.

What did you expect to happen, and what actually happened instead?

I expected the new version to be found and downloaded, but the go get command fails with verifying github.com/mholt/archiver@v3.2.0+incompatible/go.mod: github.com/mholt/archiver@v3.2.0+incompatible/go.mod: reading https://sum.golang.org/lookup/github.com/mholt/archiver@v3.2.0+incompatible: 410 Gone

How do you think this should be fixed?

From what I can read in issues in the the go repo (https://github.com/golang/go) they have some some problems with the +incompatible syntax in 1.13. Maybe you should look into switching to the github.com/mholt/archiver/v3 import name convention to avoid the +incompatible all together?

[nmiyake]

+1 -- the module name for the current project is not compatible with the major version being >=2.

Per https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher, the module name needs to include the major version number to be valid.

Per the above, the suggested approach (most compatible with non-module Go code continuing to consume the library) would be to create a new v4 directory, add a module declaration for v4 there, copy existing code into there (and update imports) and then tag the repository as v4.0.0 and continue development in the v4 subdirectory.

You could also just update the module name in the top-level go.mod file to include the major version, but that could cause issue with non-module consumers.

[nmiyake]

Specifically, it appears that the module conversion for this repository ran into a common pitfall for converting repositories at v2+: golang/go#31543

[mholt]

Yep, the readme needs to be updated.

Installation should be implicit when using as a library. Simply import github.com/mholt/archiver/v3 and the go commands will take care of the rest.

Or you can add it to your go.mod manually with:

$ go get github.com/mholt/archiver/v3

[nmiyake]

This currently doesn't work due to the way the module is declared at https://github.com/mholt/archiver/blob/master/go.mod#L1 -- in order for this to work, the module needs to be defined as module github.com/mholt/archiver/v3 with the "v3" suffix.

Current output:

➜ mkdir foo && cd $_  
➜ go mod init foo                 
go: creating new go.mod: module foo
➜ go get github.com/mholt/archiver/v3
go get github.com/mholt/archiver/v3: module github.com/mholt/archiver@upgrade found (v3.1.1+incompatible), but does not contain package github.com/mholt/archiver/v3
➜ cat go.mod 
module foo

go 1.13
➜ go get github.com/mholt/archiver   
go: finding github.com/xi2/xz latest
➜ cat go.mod
module foo

go 1.13

require (
	github.com/dsnet/compress v0.0.1 // indirect
	github.com/golang/snappy v0.0.1 // indirect
	github.com/mholt/archiver v3.1.1+incompatible // indirect
	github.com/nwaples/rardecode v1.0.0 // indirect
	github.com/pierrec/lz4 v2.3.0+incompatible // indirect
	github.com/xi2/xz v0.0.0-20171230120015-48954b6210f8 // indirect
)

[mholt]

You're right -- submit a PR if you'd like :) I'm swamped for the next couple days.

[nmiyake]

Opened PR at #190.

That approach updates the module name to "v3" -- that will fix new fetches, but existing imports will need to be updated to the "v3" path for modules.

I think this is the approach that makes the most sense, but for completeness will note that another approach (advocated by some of the linked documentation) is to bump the major version for module support and create a new subdirectory for the new major version -- this would involve adding a "v4" directory, copying all code there and then creating a "/v4" module there (this is the most compatible path for supporting importing the package from both pre-module code and new module code). However, that would be a much bigger organizational change, so going with the simpler approach for this transition.