Issue with using v2 in go module project

[KayoticSully]

I'm attempting to upgrade my project to use mangos v2 and am having issues compiling it. My project is using the go modules feature. When I compile my application from a simlinked direectory in the normal $GOPATH/src/github.com/... location it can compile just fine.

When I try to compile the project with go modules turned on from my ~/projects/... directory I see the following error: cannot find module for path nanomsg.org/go/mangos/v2

Is this library incompatible with go modules at this time? v1 works just fine which is confusing.

[gdamore]

On Nov 21, 2018, 1:44 PM -0800, Ryan Sullivan ***@***.***>, wrote: I'm attempting to upgrade my project to use mangos v2 and am having issues compiling it. My project is using the go modules feature. When I compile my application from a simlinked direectory in the normal $GOPATH/src/github.com/... location it can compile just fine. When I try to compile when go module turned on from my ~/projects/... directory I see the following error: cannot find module for path nanomsg.org/go/mangos/v2 Is this library incompatible with go modules at this time? v1 works just fine which is confusing.

I have not tested modules yet.  I’ll give it a shot, maybe I busted it somehow.  - Garrett

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[KayoticSully]

Thanks, I really appreciate it!

[gdamore]

You do know that the import path is not from github right??? Its nanomsg.org/go/mangos/v2 ...

[gdamore]

So this is bonkers. I think this is a bug in the new go module code:

It seems to be attempting to download an intermediate path, which is invalid (and which we never import):

go: finding nanomsg.org/go/mangos/v2 latest
go: finding nanomsg.org/go/mangos/v2/protocol latest
Fetching https://nanomsg.org/go/mangos?go-get=1
Parsing meta tags from https://nanomsg.org/go/mangos?go-get=1 (status code 200)
Fetching https://nanomsg.org/go?go-get=1
Parsing meta tags from https://nanomsg.org/go?go-get=1 (status code 404)
Fetching https://nanomsg.org?go-get=1
Parsing meta tags from https://nanomsg.org?go-get=1 (status code 200)
build demo: cannot find module for path nanomsg.org/go/mangos/v2

I'm not sure what is going on there. There is zero reason for it to be accessing the parent directory of go/mangos/v2 ... I've stashed a meta file there, but notably go/mangos isn't a legal import path, and is never used directly in my code.

[gdamore]

I've filed an issue against go itself: golang/go#28917

We'll see what they say.

[gdamore]

Btw, I will remind you that go modules are "experimental", so I don't necessarily consider them ready for "production use".

[KayoticSully]

Oh wow thanks for finding that. Yea I've been using the correct import but was running into the issue you found.

And yea, I'm not using it in production yet. Just experimenting with them to work out kinks like this one.

Thanks again though!

[gdamore]

It may be that we need to put a go.mod file in our project.. this was not clear from the go modules documentation.

[KayoticSully]

I would find that strange considering v1 works just fine. Unless v1 doesn't have a vanity url? I thought it did.

[gdamore]

So apparently v2 of a package is handled separately. I'll follow up with a go module.

[teleclimber]

Hello,

It seems we are still not able to use Mangos-v2 from a Go module. The simplest possible Go program (see below) fails to build:

package main

import (
        "fmt"
        "nanomsg.org/go/mangos/v2"
)

func main() {
        fmt.Println(mangos.OptionRaw)
}

$ go build
go: finding nanomsg.org/go/mangos/v2 latest
build github.com/teleclimber/nanomsgtest: cannot find module for path nanomsg.org/go/mangos/v2

I tried under Go 1.11.4, 1.11.5 and 1.12.beta1.

I was hoping this would "fix itself" with 1.12, but no luck. :(

Thank-you and sorry to bring this up again, I know the transition to Go modules is exasperating.

[gdamore]

I'll try to fix this sometime during the weekend. Probably I'll make a v3 module, and I may do this as a branch of the old v1 repo. I need to find some time to run experiments to make sure that I can do this safely without breaking things for other folks.

[gdamore]

I'm running behind... but haven't forgotten. Stay tuned.

[ghost]

@gdamore I spent couple of hours on this and this issue seems to be related to the canonical import path feature (nanomsg.org/go/mangos/v2) does not seem to support module versioning >= v2.

[gdamore]

Did you try to import using nanomsg.org/mangos/v3 -- I've posted a v3 that is the same as v2, but supports modules. It's "alpha" because I'm not 100% sure I've done the right thing yet, but please give it a shot. I've spent more than a couple of hours trying to get import paths and vanity to work together.

[ghost]

@gdamore Yes /v3 works! great!

[nanjj]

I suggest use nanomsg.org/go/mangos for version 2 or later, nanomsg.org/go-mangos for version 1.

Administrators need to do:

1. keep nanomsg.org/go-mangos as it is:

   <meta name="go-import" 
   content="nanomsg.org/go-mangos git https://github.com/nanomsg/mangos">
   

2. redirect nanomsg.org/go/mangos to github.com/nanomsg/mangos-v2:

   <meta name="go-import" 
   content="nanomsg.org/go/mangos git https://github.com/nanomsg/mangos-v2">
   

3. Delete v2(https://nanomsg.org/go/mangos/v2/), v3(https://nanomsg.org/go/mangos/v3/) redirecting.
4. Replace nanomsg.org/go/mangos/v2 with nanomsg.org/go/mangos in mangos-v2 repo, push to repo,
5. Delete tag v2.0.0 in repo mangos-v2, create new tag 1.x.x on repos mangos-v2(go mod has special handing on v2 or v3 in import path, so please do not use them, keep using v1.x.x. See: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher)

So for end users they can go get nanomsg.org/go/mangos/... in go mod or not, and go get nanomsg.org/go-mangos in go classic GOPATH(as mangos 1 readme said).

I did a test on this approach:

1. mangos meta: curl https://nanjj.github.io/nanomsg/mangos/,
2. go-mangos meta: curl https://nanjj.github.io/nanomsg/go-mangos/,
3. mangos repo: https://github.com/nanjj/mangos,
4. go-mangos repo: https://github.com/nanjj/go-mangos,
5. A testing project: https://github.com/nanjj/cub.

You can run go get -t -v github.com/nanjj/cub with go module or without go module.

[ghost]

@gdamore V3 is gone! and v2 is broken.

[gdamore]

v2 should be back, without modules support. Back to where we started this mess.

No modules support for mangos at present.

The golang people have offered me zero way to support both modules and legacy go get. Given a choice between breaking mangos for my existing users, and supporting modules, I choose to avoid breaking legacy users.

I may elect not to support modules in Mangos until the go people fix their stuff to work.

Alternatively, I may fork the project with a new name, and abandon further work on mangos. This would allow me to ditch the semver, which is partly responsible for the problems.

I have lost several days trying to make this all work, and from what I can tell the Go people JUST DO NOT CARE and have happily gone forward with the modules plan, even though it is a BREAKING CHANGE.

To say that I'm upset with the go modules project is a vast understatement.

[gdamore]

I'm tempted to just punt on this entirely, in "protest" over the handling of go modules in the 1.x release cycle if nothing else. Clearly this stuff works with non-module behavior. Just as clearly it fails to function with modules. This is absolutely, 100%, a breakage in the modules project, and I've suffered enough punishment over it. Maybe someone with enough clout/influence can go talk with the go people, and explain just how impolite it is to go around breaking stuff.

For the record, this is probably about the third time that I've had to make changes to fix brokenness caused by changes in go. I'm sick and tired of the empty Go 1 promise, because they clearly didn't actually mean it.

[gdamore]

So upstream go has a bug fix coming that addresses this. Nothing more I can do about this. #81 covers this issue, so I'm closing this as a dup of that. In the meantime, I'm sorry, but mangos and modules are incompatible pending the fixes to go itself.