question: what happens if you wanna organize your software in modules? so for example, a main module (package main) and a secondary module (core). Do you init both as separate modules? and then you use the second as dependency on the first one? do they have to be actually published somewhere to be accessible in this way?
Using Go Modules
11–20 of 124 posts
Re: Using Go Modules
#12Making sure I understand this: I’m some independent developer working in many languages. I like every project I work on to be inside ~/work/ within a subdir I name based on the project. I used to be annoyed that I had to put every go project into a dir 7-8 layers below that e.g ~/work/go/src/github.com/joshklein/project/cmd/hello_world.go, but now I can have ~/work/go_hello/src/main.go. Right? I understand this isn’t…
That's how I understand it reading that page.
Re: Using Go Modules
#13I've been using Go modules, and I really like them. It's obvious they really paid a lot of attention to backwards compatibility. Being able to vendor using mod is really awesome, as well as see all your transitive dependancies automatically. It's very goish to focus on minimizing your dependancies and actually think about what you're pulling in. I'm not yet sure how I feel about the v2+ stuff. Having a separate modul…
It does not put modules in GOPATH, at least not where you'd normally find them. Pre-modules github.com/foo/bar would be in $GOPATH/src/github.com/foo/bar. Now they are in $GOPATH/pkg/mod/... (... being based on the URL with some handling for versions and characters that don't work well in filesystems, I don't know the exact details). The main problems I've had with go modules are fast-and-loose upstreams that happily…
That's what I meant, pkg is definitely in GOPATH. It's annoying because I can't put my code in src anymore, which is where I've been organizing it for years, but I still have to keep GOPATH around for bin and pkg.
Re: Using Go Modules
#14The main thing that annoys me about Go modules is that it broke so much tooling. I still can't get GoCode to work properly, and there are 4 or 5 different forks of the repo all trying to add module support, its a mess.
Can't you just keep using GOPATH until they're fixed?
Re: Using Go Modules
#15question: what happens if you wanna organize your software in modules? so for example, a main module (package main) and a secondary module (core). Do you init both as separate modules? and then you use the second as dependency on the first one? do they have to be actually published somewhere to be accessible in this way?
By definition of you calling main and core modules, yes, you would init both. They would both need to be available via git source control, but otherwise go mod is going to go get the virtualized path that's written into the mod file the same as if you had done it yourself with go get, so nothing has really changed.
Re: Using Go Modules
#16The main thing that annoys me about Go modules is that it broke so much tooling. I still can't get GoCode to work properly, and there are 4 or 5 different forks of the repo all trying to add module support, its a mess.
Can't you just keep using GOPATH until they're fixed?
You can, go mod is completely opt in.
Re: Using Go Modules
#17Making sure I understand this: I’m some independent developer working in many languages. I like every project I work on to be inside ~/work/ within a subdir I name based on the project. I used to be annoyed that I had to put every go project into a dir 7-8 layers below that e.g ~/work/go/src/github.com/joshklein/project/cmd/hello_world.go, but now I can have ~/work/go_hello/src/main.go. Right? I understand this isn’t…
I actually organize all my projects using the go way, there's nothing that stops you from coexisting Haskell in the Go tree. The advantage is that if you are working on something like the kernel, you can maintain separate branches easily. That said, mod allows you to put your project anywhere but in the GOPATH, so the answer to your question is yes. The path is virtualized in the mod file.
[deleted]
Re: Using Go Modules
#18Google API's latest semantic version is behind the doc site (godoc.org/google.golang.org/api). Is this standard practice in Go?
I was coincidentally converting my Go project to use Go modules yesterday. I depended on a Google API which was originally retrieved via 'Go get', corresponded to docs and worked fine as this pulled from HEAD. `go mod` did not work out of the box, as it required the latest semantic version (v.0.2.0) of my this Google API import. This version, however, is behind documentation and broke my code.
I understand I can require a specific commit in the go.mod file, but the strings for specific commit seem cryptic. Where can I look up the version hash that matches the doc site?
Re: Using Go Modules
#19The main thing that annoys me about Go modules is that it broke so much tooling. I still can't get GoCode to work properly, and there are 4 or 5 different forks of the repo all trying to add module support, its a mess.
Gocode works in vim but for some reason won't do autocomplete in spacemac's go-mode. I haven't found the time to look for a fix yet. There's a fork of Gocode that fixes it, but makes vim's autocomplete very very slow. As someone who switches between vim and emacs I wish this mess gets sorted out soon!
Re: Using Go Modules
#20Making sure I understand this: I’m some independent developer working in many languages. I like every project I work on to be inside ~/work/ within a subdir I name based on the project. I used to be annoyed that I had to put every go project into a dir 7-8 layers below that e.g ~/work/go/src/github.com/joshklein/project/cmd/hello_world.go, but now I can have ~/work/go_hello/src/main.go. Right? I understand this isn’t…
> I used to be annoyed that I had to put every go project into a dir 7-8 layers below that e.g ~/work/go/src/github.com/joshklein/project/cmd/hello_world.go, but now I can have ~/work/go_hello/src/main.go. Right?
yes