Setting up go module (vgo) for existing v2 project

[Justin Israel]

I'm trying to give the new module support in 1.11 tip a try, as per Dave's post: 

https://dave.cheney.net/2018/07/14/taking-go-modules-for-a-spin

My existing project is up to v2.6.1 tag, and has been using glide. So I did the following:

• Migrate glide vendor files to project root, in prep of module
• go mod -init -module go mod -init -module github.com/justinfx/gofileseq/v2 
• Re-vendor, commit, tag v2.6.2

In a random new main project, I tried to require the new module a number of different ways, but getting failures each time:

go mod -require=github.com/justinfx/gofi...@2.6.2

go build 

  go: github.com/justinfx/gofi...@v0.0.0-20180715053615-2a03c8cc8a9f: go.mod has post-v0 module path "github.com/justinfx/gofileseq/v2" at revision 2a03c8cc8a9f

  go: error loading module requirements

           

go mod -require=github.com/justinfx/gofileseq/v...@2.6.2             

go build

  go: finding github.com/justinfx/gofileseq/v2 v2.6.2

  go: finding github.com/justinfx/gofileseq latest

  go: downloading github.com/justinfx/gofileseq v0.0.0-20180715053615-2a03c8cc8a9f

  go: import "github.com/test/test" ->

import "github.com/justinfx/gofileseq": cannot find module providing package github.com/justinfx/gofileseq

I'm just a bit confused as to how to get this existing project to work as a v2 module. Do I have to duplicate it into a v2 subdir? Am I missing a step for getting it to work without the subdir?

Basically, my first experience using Go Modules has been a bit confusing, compared to my experience using glide which has always "just worked". 

Much apprecated for some pointers,

Justin

[Paul Jolly]

Hi Justin,

Your module's import path is now github.com/justinfx/gofileseq/v2
(given it has major version v2)

Therefore imports of packages within the module also need to reference
the github.com/justinfx/gofileseq/v2/... import path:

If you change:

https://github.com/justinfx/gofileseq/blob/2a03c8cc8a9f8655fec0c97c7087372b80724ab7/frameset.go#L6

to:

"github.com/justinfx/gofileseq/v2/ranges"

then you should be set.

Indeed I confirmed this locally by using a replace directive:

cd `mktemp -d`
mkdir hello
cd hello
go mod -init -module example.com/hello
cat <<EOD > main.go
package main
import _ "github.com/justinfx/gofileseq/v2"
func main() {}
EOD
git clone https://github.com/justinfx/gofileseq ../gofileseq
sed -i 's+"github.com/justinfx/gofileseq/ranges"+"github.com/justinfx/gofileseq/v2/ranges"+'
../gofileseq/frameset.go
go mod -require github.com/justinfx/gofileseq/v...@v2.6.2
go mod -replace github.com/justinfx/gofileseq/v2=../gofileseq
go build


Paul

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Justin Israel]

Hi Paul,

Thanks for the explanation and all of this extra work to confirm the fix. I just tested it and it does now build as expected.

So, I was hoping to introduce the go.mod in a way that didn't involve changing my import paths. While I see how this now works... going back to my original question, is there a way to introduce Go modules to an existing v2 project in a way that won't break it for non-module-aware Go versions? If I were to make the required changes to the import paths, adding in "v2", wouldn't this break usages outside of Go modules? Now my sub-packages reference "v2" in the import path, which only makes senes to go.mod. If someone is vendored to a specific commit, then they should be fine when cloning it. But it would seem like go 1.10 would break, since there would be no physical "v2" location. Does that mean I really would need to copy everything into a v2 subdirectory to prevent breakage?

Justin

[Paul Jolly]

Hi Justin,

> So, I was hoping to introduce the go.mod in a way that didn't involve changing my import paths. While I see how this now works... going back to my original question, is there a way to introduce Go modules to an existing v2 project in a way that won't break it for non-module-aware Go versions? If I were to make the required changes to the import paths, adding in "v2", wouldn't this break usages outside of Go modules? Now my sub-packages reference "v2" in the import path, which only makes senes to go.mod. If someone is vendored to a specific commit, then they should be fine when cloning it. But it would seem like go 1.10 would break, since there would be no physical "v2" location. Does that mean I really would need to copy everything into a v2 subdirectory to prevent breakage?

Go 1.10.3 and 1.9.7 were released for exactly this reason; they are
sufficiently aware of versioned import paths to know what to do. That
way you can safely create modules with v >= 2 (because that's when
versioned import paths become significant) and have 1.10.3 and 1.9.3
still work as they did before.


Paul