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

51–60 of 124 posts

Re: Using Go Modules

#51

Post by LukeShu »

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…

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

Go also allows freeform textual suffixes, it just needs a `+` in there: v1.2.3+bigco1, v1.2.3+bigco2.

Re: Using Go Modules

#52

Post by LukeShu »

mikepurvis wrote: post #38
skybrian wrote: post #34

Earlier quoted context omitted.

For a single module, there is a "replace" directive that you can use to point to a local fork: https://github.com/golang/go/wiki/Modules#when-should-i-use-... But if you have an internal version that's used in lots of modules, it's probably better to use an import path under your own organization, to avoid confusion.

Does this account for the scenario where you have a dependency of a dependency? For example, if I'm patching a bug in something that several of my upstream dependencies import, do I have to fork/replace everything in that chain to get it to do the right thing? Debian packages can Replace each other too, and that's certainly an option for managing this scenario, but I feel it's often more disruptive— it's a much more…

No, you don't need to fork/replace everything in the chain. A `replace` in the top-level `go.mod` applies in all places where that package is used.

Doing a fork/replace on everything in the chain will have no affect; `replace` is only obeyed for the top-level `go.mod`, `replace` in dependencies is ignored.

Re: Using Go Modules

#53

Post by LukeShu »

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.

There's a reason why Go 1.12 still doesn't set GO111MODULE=on by default. They're waiting until not so much tooling is broken on modules.

Re: Using Go Modules

#54

Post by jerf »

fiatjaf wrote: post #42

All I wanted was a way to safely and easily cleanup my $GOPATH. I don't have a lot disk space and $GOPATH takes up most of it. This thing apparently doesn't solve my problem. `go mod tidy` simply removes a dependency from a module, but that dependency is still cached in a big arcane directory at $GOPATH/src/mod. Why? I think we all should be using something like Nix for dependency management that solves all problems,…

Not having a lot of disk space is a minority case for developers now. I wouldn't hold your breath for the Go authors to address it.

If you have a disk space problem, Nix would seem to be the opposite of the solution to that. One of the ways Nix does its magic is to chew through disk space a lot more freely than most distros do.

Re: Using Go Modules

#55

Post by humblebee »

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.

When I first started using go I also was a bit annoyed at the fact that I had to have everything in my gopath, particularly when I forked a repo as none of the paths would lead to my fork.

I've since started to also organize all of my code the gopath way and I just set $GOPATH to $HOME. When forking I just add a new remote and work out of the upstream repo, which seems saner now as it reduces object duplication.

I don't know if I will ever move away from organizing my node this way if I can help it.

> That said, mod allows you to put your project anywhere but in the GOPATH

I don't know if I've run into this yet, though the only project[0] I've used gomod with has a makefile so it might do something to handle it.

[0] https://github.com/ipfs/go-ipfs

Re: Using Go Modules

#56

Post by weberc2 »

kyrra wrote: post #25
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

This hasn't been my experience. VSCode still regularly fails to resolve dependencies for me. Usually it's because I added a go.mod after opening VSCode and I just need to restart the latter, but sometimes even that doesn't work. Hard to say exactly what the cause is since debugging VSCode is quite difficult (or maybe I'm just looking in the wrong places).

Re: Using Go Modules

#57

Post by farslan »

throwaway8879 wrote: post #19
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.

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!

HEAD of vim-go has now gopls support, which has excellent support for Go modules for code completion and jumpt to definition. Give it a try.

Re: Using Go Modules

#58

Post by farslan »

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.

This is now mostly fixed with "gopls". It's using go/packages under the hood which is both GOPATH and Go modules aware. gopls has also caching inbuilt, both code completion and jump to definition works very well.

If you're using vim-go, HEAD has now gopls support. I believe vscode also added recently support for gopls.

Other than, I agree that it broke all other tools, but most of them are migrated to use the go/packages package so it'll be better going forward.

Re: Using Go Modules

#59

Post by hiimnate »

lsllc wrote: post #29
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

Not all go tools respect symlinks, since Rob Pike decided that symlinks should not be supported.

https://github.com/golang/go/issues/15507#issuecomment-24158...

Re: Using Go Modules

#60

Post by weberc2 »

mirceal wrote: post #35

Every mainstream programming language that came out in the last 20 years has already solved this. Java, Javascript, Ruby, Python, Rust, you name it. I am baffled to why Go has not figured this out and are presenting recent developments as some kind of breakthroughs - they are not. To me, and I'm not trying to be disrespectful here, because of the shortcomings it has, Go is in the experimental/keep an eye on bucket. I…

Go's modules are quite a lot nicer than Java's or Python's dependency management / build tools. JavaScript only recently got its act together. Can't speak to Ruby, but Rust is the only one that got it right the first time. Dependency management is only recently a "solved problem".

> Go me, and I'm not trying to be disrespectful here, because of the shortcomings it has, Go is in the experimental/keep an eye on bucket. It does some things really, really well but it's far from the panacea most developers that use it think it is.

Go is definitely a production-ready language, and indeed it powers much of the most important software that has been written since it went 1.0 (particularly in the Cloud and DevOps spaces). It's not perfect, but it's really, really good and improving steadily.

Post reply on HN