How do you use pkg with go module?


(Robert Sung Wook Shin) #1

Because I could manage each pkg directories separately in several projects, I love GOPATH with vscode-go.
But now, it seems not possible to do it with module.

I wonder how people manage their dependencies.
Like me nor just mix it in a single pkg directory under GOPATH?


(J S) #2

I was just going to ask a similar question I’ve got a GOPATH with 9 exe’s and 4 folders with shared code between those exe’s each of these has external dependencies as well. So I love the idea of the new dependency management! but it simply won’t compile after adding it and I’ve had to revet back to the old way. (I also treat my folder as a monolith repository)

So I’m all ears as well on how to handle these I read the docs and all makes sense but it don’t work in practice :man_shrugging:


(Jakob Borg) #3

So far I’ve managed to keep the things that are developed together into a single module. This seems the by far easiest way to go about it, avoiding replace directives and stuff.


(Robert Sung Wook Shin) #4

One source, one binary, it seems one of best answer.
I worked as a single module in some projects. Maybe I’m not wrong. :slight_smile:


(J S) #5

Well I personnally am making microservices. So I will have many binaries but it dosn’t mean there isn’t shared code (message contracts / utility methods etc) All of these services are versioned together as well.


(Robert Sung Wook Shin) #6

I’m not sure below way which I’m trying but I’m trying this and some other ways.

I’m trying to use go mod vendor after go mod tidy then go build -mod vendor.
All is good in practice(this and this) except require manual modifying go.mod files in each packages at every initial work.:joy:

Anyway, I don’t touch gopath anymore except when lack of disk space.

Until release go 1.12, maybe I would to use this way.
Also, hope that better way would be appeared.


(J S) #7

I am actually wondering if GoLand is my problem it does support vgo but I am wondering if it’s failing to set GO111MODULE as required.

Going to try the 2018.3 EAP later :slight_smile:


(Robert Sung Wook Shin) #8

Although, I’m not an user of GoLand…

Default value of GO111MODULE is auto so, if your project path is not under GOPATH, the env, GO111MODULE is not required to set.


(J S) #9

I think my problem is it just dosn’t accept anything above the parent folder for the module so I think I need to init at the root. Going to try that later. But essentially this puts it back to how GOPATH was! :slight_smile:


(Jakob Borg) #10

I guess you can see it as the module being a GOPATH-like universe of its own, yes. For me, having the module coincide with the repository, and having some repositories be monorepo-like works out well.