Live data from Hacker News

Using Go Modules

blog.golang.org

91–100 of 124 posts

Re: Using Go Modules

#92
post #9

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…

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.

Re: Using Go Modules

#93
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…

It's how basically the entire language is, they keep reinventing the wheel, only in a subpar way and market it as if it's some breakthrough, and people who don't know better drink the Koolaid. golang wouldn't have gone anywhere if it didn't have the Google name behind it. Did you even notice how verbose the testing code was in that post?

Re: Using Go Modules

#94
post #9

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…

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.

Re: Using Go Modules

#95
post #47
post #40

"the go command automatically looks up the module containing that package" Looks up where? GOPATH? The tree below the current file? The current directory? What's the "current module", anyway? Where is that stored? "go: downloading rsc.io/sampler v1.3.0" Downloading from where? Github? From what repository? The page for "go get" now talks about "module-aware" mode, but doesn't make it clear how that works. This is the…

> What's the "current module", anyway? Where is that stored? The article uses "current module" like you might use "current git repository"; it's the module containing the directory that you are currently `cd`ed to. Just as git identifies the repo by looking for `.git` in successive parent directories, go identifies the module by looking for `go.mod` in successive parent directories. > > "go: downloading rsc.io/sample…

As far as I can tell, rsc.io/sampler isn't a git repository, so it's not doing the same stuff `go get` does. If I try to clone it I just get hit by the HTTP redirect to the docs for rsc.io/sampler.

I may be missing something here (it's been quite a while since I did serious Go stuff so `go get` may have changed too)

> Does it, though? It's a blog-post, not the "normal" documentation. The full docs are much more explicit and nitty-gritty than a high-level blog post.

It's a bit weird to have a blog post about the new module system with nothing about how modules can be published, a pretty common task.

Re: Using Go Modules

#96
post #60
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.…

Not sure what you're talking about, Java's dependency management system is strictly superior.

Most important software is quite a claim as well.

Re: Using Go Modules

#97
post #76
post #60

Earlier quoted context omitted.

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

nah. we’ll agree to disagree on this one. most devops cloud stuff is written in python. you know what’s written in go? terraform. i have yet to meet someone that has actually leveraged terraform in a production setting and does not think it should be banned. what else? k8s? the favorite poster boy of our generation. solving problems you don’t have and replacing figuring out how to deploy your stuff with the anguish o…

I'm curious as to how much golang is even used inside Google itself, since they actually have to write maintainable code that does nontrivial stuff, and not follow the latest fads

Re: Using Go Modules

#98
post #91

How do you reference local go modules that are under development? The equivalent in node is `npm link`.

with a `replace` entry. e.g.

    replace (
        github.com/repo/module/path vX.X.X => /path/to/github.com/repo/module/path
    )

Re: Using Go Modules

#99
post #40

"the go command automatically looks up the module containing that package" Looks up where? GOPATH? The tree below the current file? The current directory? What's the "current module", anyway? Where is that stored? "go: downloading rsc.io/sampler v1.3.0" Downloading from where? Github? From what repository? The page for "go get" now talks about "module-aware" mode, but doesn't make it clear how that works. This is the…

rsc.io is a URL. It's being downloaded from there.

Re: Using Go Modules

#100
post #47

Earlier quoted context omitted.

> What's the "current module", anyway? Where is that stored? The article uses "current module" like you might use "current git repository"; it's the module containing the directory that you are currently `cd`ed to. Just as git identifies the repo by looking for `.git` in successive parent directories, go identifies the module by looking for `go.mod` in successive parent directories. > > "go: downloading rsc.io/sample…

As far as I can tell, rsc.io/sampler isn't a git repository, so it's not doing the same stuff `go get` does. If I try to clone it I just get hit by the HTTP redirect to the docs for rsc.io/sampler. I may be missing something here (it's been quite a while since I did serious Go stuff so `go get` may have changed too) > Does it, though? It's a blog-post, not the "normal" documentation. The full docs are much more expli…

> As far as I can tell, rsc.io/sampler isn't a git repository, so it's not doing the same stuff `go get` does. If I try to clone it I just get hit by the HTTP redirect to the docs for rsc.io/sampler.

Why would you try to `git clone` it directly instead of trying to `go get` it?

    $ GO111MODULE=off go get -v rsc.io/sampler
    Fetching https://rsc.io/sampler?go-get=1
    Parsing meta tags from https://rsc.io/sampler?go-get=1 (status code 200)
    get "rsc.io/sampler": found meta tag get.metaImport{Prefix:"rsc.io/sampler", VCS:"git", RepoRoot:"https://github.com/rsc/sampler"} at https://rsc.io/sampler?go-get=1
    rsc.io/sampler (download)
    created GOPATH=/home/lukeshu/tmp-go; see 'go help gopath'
    Fetching https://golang.org/x/text/language?go-get=1
    Parsing meta tags from https://golang.org/x/text/language?go-get=1 (status code 200)
    get "golang.org/x/text/language": found meta tag get.metaImport{Prefix:"golang.org/x/text", VCS:"git", RepoRoot:"https://go.googlesource.com/text"} at https://golang.org/x/text/language?go-get=1
    get "golang.org/x/text/language": verifying non-authoritative meta tag
    Fetching https://golang.org/x/text?go-get=1
    Parsing meta tags from https://golang.org/x/text?go-get=1 (status code 200)
    golang.org/x/text (download)
It's been that way since at least 1.2 (I'm pretty sure since 1.0, but I haven't verified that memory). The process that `go get` follows is described by `go help importpath`.

The TL;DR is that it fetches `https://${pkgpath}?go-get=1`, and looks for `` to tell it where to `git clone` from (with some hard-coded hacks for common websites that don't support that, like github.com).

> It's a bit weird to have a blog post about the new module system with nothing about how modules can be published, a pretty common task.

Because that hasn't changed. You still publish packages the same way you always have. The only difference in how you publish is that now "vSEMVER" git tags mean something.

Post reply on HN