what does "go mod: cannot use outside module" mean

[Dan Kortschak]

Looking into the necessity of a go.mod sync I get this at the root of
the gonum/gonum repository:

```
~/src/gonum.org/v1/gonum [master*]$ go mod -sync
go mod: cannot use outside module
```

but

```
~/src/gonum.org/v1/gonum [master*]$ go mod -init
go mod -init: go.mod already exists
```

The first error is extremely unhelpful. What does it mean?

thanks

[Sam Whited]

Is your GOPATH set to $HOME? If so then anything inside ~/src will use the old vendor directory / go get behavior for fetching packages (i.e. it is a Go package, not a module).

Either move the package outside of $GOPATH/src or set GO111MODULE=on to force the new behavior everywhere.

—Sam

> --
> 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.


--
Sam Whited
s...@samwhited.com

[Dave Cheney]

I hit the same issue, https://github.com/golang/go/issues/26365

The TL;DR is the module behaviour is disabled inside gopath. Export GO111MODULE=on to disable vendor/ folder support and enable modules everywhere — or move your working folder outside gopath.

Dave

[Dan Kortschak]

Thanks.

That's pretty unfortunate design - with a surprisingly bad error
message.

I have my GOPATH=$HOME, so I will have to set GO111MODULE=on.

Dan

[Ian Davis]

On Tue, 17 Jul 2018, at 6:16 AM, Dan Kortschak wrote:
> Thanks.
>
> That's pretty unfortunate design - with a surprisingly bad error
> message.
>
> I have my GOPATH=$HOME, so I will have to set GO111MODULE=on.

You just need to move outside $GOPATH/src

Ian

[Jan Mercl]

On Tue, Jul 17, 2018 at 9:37 AM Ian Davis <m...@iandavis.com> wrote:

> You just need to move outside $GOPATH/src

Years ago I set $GOPATH to $HOME and never had to think about it again. It makes me sad I now have to.

I'm sometimes using a function that finds where a repository is located on disk based on its import path - to access assets from that repository. Only today I realized, that the above requirement - move outside $GOPATH/src - that some will adopt, probably ruins that completely. Can someone confirm that? If it is so, what's the best practice to achieve the same goal in the new setup where programs may be installed from non-discoverable locations? (Not considering searching from / an option.)

--

-j

[Dan Kortschak]

I'm going to reiterate Jan's sentiments here. It's like saying, "You
just need to move out of your house" or "You just need to change
completely the way that you do things".

This makes me sad.

[Ian Davis]

On Tue, 17 Jul 2018, at 10:02 AM, Dan Kortschak wrote:
> I'm going to reiterate Jan's sentiments here. It's like saying, "You
> just need to move out of your house" or "You just need to change
> completely the way that you do things".
>
> This makes me sad.
>

I too have $GOPATH =$HOME and am used to working in ~/src/github.com/iand/whatever but moving to ~/wip/whatever isn't a big step in the scale of things.

Ian

[wilk]

On 17-07-2018, Dan Kortschak wrote:
> I'm going to reiterate Jan's sentiments here. It's like saying, "You
> just need to move out of your house" or "You just need to change
> completely the way that you do things".
>
> This makes me sad.

If I understand correctly (correct me) what rsc just said :
https://groups.google.com/d/msg/golang-dev/a5PqQuBljF4/ZgmUvCGVBwAJ

If GO111MODULE=auto (the default)
Inside GOPATH it's like GO111MODULE=off, it doesn't change the current
behaviour.
Outside GOPATH : it's like GO111MODULE=on you can experiment with module

If you want to force the new modules under GOPATH you have to set
GO111MODULE=on (and don't need to move your code)

--
William

[Jan Mercl]

On Tue, Jul 17, 2018 at 11:13 AM wilk <wi...@flibuste.net> wrote:

> If you want to force the new modules under GOPATH you have to set
> GO111MODULE=on (and don't need to move your code)

That's the easy part and I will probably do exactly that. The problem I don't know a solution for is _someone else_ using my program installed from a location outside $GOPATH. But the program relies on being able to find its repository path (using its own import path and $GOPATH) at runtime to access assets included in the repository. It's not always feasible to bundle them in the binary (size etc.).

--

-j

[Jakob Borg]

Expecting an installed program to also have its own source repository available in a magic location seems an odd requirement to begin with. Something like an -assets=$dir parameter to the program would be less unexpected to me. 

--

[Jan Mercl]

On Tue, Jul 17, 2018 at 12:55 PM Jakob Borg <ja...@kastelo.net> wrote:

> Expecting an installed program to also have its own source repository available in a magic location seems an odd requirement to begin with. 

It depends. Consider a C compiler front end that has a ton of test data in https://github.com/cznic/cc/tree/master/v2/testdata. The Go back end repeats most of the test data at https://github.com/cznic/ccgo/tree/master/v2/testdata. (It seems I've ran into this problem before and then forgot about it.) With the former reliable way of searching for import path within GOPATH(s) it would be possible to share the testdata because the back end imports the front end.

> Something like an -assets=$dir parameter to the program would be less unexpected to me. 

Or some configuration file, of course (however, still in some magic location, BTW). But zero config beats all of that, doesn't it?

--

-j

[Jakob Borg]

On 17 Jul 2018, at 14:26, Jan Mercl <0xj...@gmail.com> wrote:
> > Something like an -assets=$dir parameter to the program would be less unexpected to me.
>
> Or some configuration file, of course (however, still in some magic location, BTW). But zero config beats all of that, doesn't it?

Almost all programs I use find their data with zero configuration, usually by assuming it’s in /usr/lib or some similar defined location, or like the Go compiler handles GOROOT. This is a solved problem. I don’t see why expecting the user of a program to have the source available and adopt Go specific directory conventions is in any way better.

//jb

[Jan Mercl]

On Tue, Jul 17, 2018 at 2:00 PM Jakob Borg <ja...@kastelo.net> wrote:

> Almost all programs I use find their data with zero configuration, usually by assuming it’s in /usr/lib or some similar defined location, or like the Go compiler handles GOROOT.

> This is a solved problem. I don’t see why expecting the user of a program to have the source available and adopt Go specific directory conventions is in any way better.

I do see a good reason to have the source repository available. To be able to run `go test` using the ton of test data that sits in the repository, for example. This is not a use case like typing `$ wget ...` in the terminal. Developers are also _users_, just with special/additional needs.

In general, many, if not most programs do not need to be able to access their source repository and/or some specially located data that may or may not reside in /usr. Some do, namely for developers, contributors, etc.

Considering this, I'm particularly talking about duplicating big test data in different repos now - while it was not necessary before. That's unfortunate.

--

-j

[Sam Whited]

On Tue, Jul 17, 2018, at 07:36, Jan Mercl wrote:
> I do see a good reason to have the source repository available. To be able
> to run `go test` using the ton of test data that sits in the repository,
> for example. This is not a use case like typing `$ wget ...` in the
> terminal. Developers are also _users_, just with special/additional needs.

If you still need to get access to the sources at runtime, you can probably load them from $GOPATH/src/mod (which is where the new system will stick them). You'll also need to know the version now but I supect there are various things you could do about that (always use latest, embed your go.mod in the binary at build time and use the version from that, etc.)

You can always use Go's loader to get this information too, I think the new one supports the new state of the world already: https://godoc.org/golang.org/x/tools/go/packages#Package

—Sam