Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Go Modules

blog.golang.org

Post reply on HN
Print view View original

21–30 of 124 posts

Re: Using Go Modules

#21

Post by jrockway »

fourseventy wrote: post #7

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

I have been using https://github.com/stamblerre/gocode with company-mode in Emacs. It mostly works. (The limitation with gocode, it seems, is that your file has to be saved and the package you want to complete from has to be listed in the imports list in order for it to do anything. Not sure if that is what is broken with modules, or just how it is. I started using gocode after I started using modules.)

Re: Using Go Modules

#22

Post by Waterluvian »

ilovecaching wrote: post #10
joshklein wrote: post #6

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

It awfully breaks when you run into multiple systems that want things done their way. Like Go and ROS workspaces.

Re: Using Go Modules

#23

Post by skybrian »

There are at least two bugs in this tutorial:

- There's a duplicated section starting with: "Note that our module now depends on both rsc.io/quote and rsc.io/quote/v3:"

- In the example of upgrading a major version, Hello was renamed to HelloV3, but the caller isn't renamed. It should be "quoteV3.HelloV3".

Re: Using Go Modules

#24

Post by antwerpen »

antwerpen wrote: post #18

Google 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 (…

Ah. The trick is to substitute in the go.mod file's require block.:

s/$SEMANTIC_VERSION_BRANCH/$BRANCH

In this case, $BRANCH == 'master'. 'go build' will resolve 'master' to a specific commit hash version.

Re: Using Go Modules

#25

Post by kyrra »

fourseventy wrote: post #7

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

The VSCode go plugin team has been doing a good job of staying on-top of this[0]. Which points to a golang bug[1] where the Go team is tracking tooling programs that need to be updated for Go Modules. So the Go team is aware of this issue and people are working to get all the major tools on board.

[0] https://github.com/Microsoft/vscode-go/wiki/Go-modules-suppo...

[1] https://github.com/golang/go/issues/24661

Re: Using Go Modules

#26

Post by mikepurvis »

I'm not an active golang user, but something which gives me pause here is the insistence on a strict 3-number semver.

For a commercial entity shipping software which may include upstream components, it's important to have options for maintaining (and versioning) in-house forks of upstream components. This becomes a problem when you fork v1.2.3 from upstream and want to internally release your fixes, but now your internal 1.2.4 and upstream's 1.2.4 both have the same number but diverge in content.

I like the Debian solution to this, which permits freeform textual suffixes, so that in the hypothetical scenario above, you can release v1.2.3bigco1, v1.2.3bigco2, with the final number indicating the version of the patchset being applied onto the upstream release; then it's also clear what to do when you rebase your fork because you've maintained the integrity of the upstream version.

Re: Using Go Modules

#27

Post by dastx »

jrockway wrote: post #9
ilovecaching wrote: post #3

I'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…

> The main problems I've had with go modules are fast-and-loose upstreams that happily rewrite history. go mod detects this and stops the world, and you have to manually edit go.sum.

This exists in other package management systems. At least, it did when I used composer and came across the same issue some 3/4 years back. I think it's one of those issues that are quite rare and in well maintained packages are even less likely.

Re: Using Go Modules

#28

Post by ilovecaching »

mikepurvis wrote: post #26

I'm not an active golang user, but something which gives me pause here is the insistence on a strict 3-number semver. For a commercial entity shipping software which may include upstream components, it's important to have options for maintaining (and versioning) in-house forks of upstream components. This becomes a problem when you fork v1.2.3 from upstream and want to internally release your fixes, but now your inte…

This has never been a problem in Go, the repo name encodes the owner of a fork, and two separate repo paths with the same version are still completely different modules.

The nice thing about not doing what debian does is that there is consistency. Freeform usually means diverging opinions, which is not the Go way.

Re: Using Go Modules

#29

Post by lsllc »

joshklein wrote: post #6

Making 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…

You can put your project in ~/work/my-go-project but then symlink it to ~/go/src/github.com/joshklien/my-go-project (assuming your $GOPATH is ~/go).

But yes, with modules you don't need to do this anymore.

go mod init github.com/joshklien/my-go-project

Re: Using Go Modules

#30

Post by ra7 »

fourseventy wrote: post #7

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

I think the language server implementation (x/tools/internal/lsp) should get rid of the need for Gocode. But I assume it's a while away.
Post reply on HN