Hacker News Reader

Comment by jrockway | Hacker News Reader

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 rewrite history. go mod detects this and stops the world, and you have to manually edit go.sum.

I also feel like "go get github.com/foo/bar" doesn't always get me the latest version. You see that there was a commit 1 hour ago, but then "go get" adds a version like 20181130-93874837 to your dependencies. I assume they know what they're doing? But I'm probably wrong.

View on HN

> 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 is really irritating. I have the same problem with TLS: every time a malicious actor tries to manipulate my connection and steal my cookies I get an error page and can't do online banking anymore!

Sarcasm aside: this is not a problem with Go modules. This is a problem with the libraries you're using and you should avoid those projects until they get their act together.

These two things are not comparable.

This prevent things like Nodejs package hijacking. I think it's a pretty big deal tbh.

From the point of view of someone considering what to use, it's often of fairly minimal significance if a problem comes from the language ecosystem or from the language technology.

Internal libraries are a huge pain to build now. I don’t need the rigor of semantic versioning for this, it just gets in the way. My act is together, I have tests that confirm my libraries work, I have a idempotent versioning system that is automatic (git sha) and if something gets merged to master that is my stamp of approval that it works.

Between the versioning behavior and trying to figure out how to document transitive dependencies correctly go mod has made my life as a maintainer harder.

It sounds like the replace syntax might help here. It allows you to forgo semver+version control and depend on modules on your local disk. https://github.com/golang/go/wiki/Modules#can-i-work-entirel...

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

Go gets the latest tag (if there are tags in the repo). You can force `go get` to check out a commit by branch or concrete hash with respectively @branchname or @commithash123. That's sometimes necessary when maintainers are lazy taggers.

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.

You don't really need bin anymore, run go install or go build with a output target. I'm doing platform independent stuff anyway so I have a json file in my projects that describes what execs I want to release and where they are in go and what the filename will be when done. I then create shim scripts for all platforms (in my multi-platform distro), or could easily just make 3 different "distributions". Yes I know this isn't using the tools idiomatically or whatever but I've found it more useful since I work with people who are on multiple platforms.

What the blog post neglected to mention is that you can force module usage, even inside $GOPATH, by setting the environment variable GO111MODULE=on. I have a go command wrapper script called vgo that sets GO111MODULE=on, which I use when I want to use modules inside $GOPATH. More info here: https://github.com/golang/go/wiki/Modules

Fair enough. I clarified because the days of editing code in some dependency of yours are over; it's not easily exposed for that purpose (but you can do it ;).

Which is, of course, totally unacceptable. This is a critical use case for doing deep-dive debugging or for code exploration. Fortunately for us there is the wonderfully named "gohack", which does easily expose your deps for editing (though not as easily as before): https://github.com/rogpeppe/gohack

I think "go get" will only grab the latest tag. If that commit an hour doens't have a new tag, it won't see anything to update.

I use go modules to avoid having to work out of $GOPATH (~/go). When I work on projects or components I have them all separate in different directories in different locations on the filesystem. Next they should put pulled git dependencies under ~/cache/go or something, not in a top level $HOME directory.

Reply on news.ycombinator.com