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

Taking Go modules for a spin

dave.cheney.net

Post reply on HN
Print view View original

31–40 of 75 posts

Re: Taking Go modules for a spin

#31

Post by sseth »

pinkgodzilla wrote: post #24
benesch wrote: post #12

Earlier quoted context omitted.

I can't speak to this with absolute certainty, but I have some speculation to offer. The story of GOPATH is tightly intertwined with the story of package management. Go is a Google project, and Google has a very unique approach to package management: commit everything to the monorepo. The GOPATH is, in essence, a monorepo. If you want to change the API of a library, well, you can just change all its callers across yo…

Can someone help me understand why people hate gopath? We have a script called govars.sh at the root of every project and it sets the gopath exactly the same way one would use virtualenv in Python. We remove the default one from .bashrc or .profile. This basically makes gopath disappear entirely - we never bother explaining to new devs what it "really" means. Just ask them to use our template project folder structure…

At least i have found it limiting when I want have a mix of languages, and i am forced to have all the go packages in the root folder or live with strange package names. Hate is used a bit too often for my liking - nuisance would be more appropriate.

You are right that it is solvable. And in many other languages the package management etc have grown independently of the core language itself, from the community. So the attacks on the golang team seem a bit strange. Maybe they thought that these solutions would come from outside the core language team.

Re: Taking Go modules for a spin

#33

Post by stephen »

hellcow wrote: post #15

I've been using go modules in my company for several months now. Everything has "just worked." It's at least 1 order of magnitude faster than dep. It's worth noting that go modules use a novel dependency resolution algorithm which is extremely simple to reason about/implement, fast, and produces more reliable builds than npm/bundler/cargo. That's why I was excited about it, anyway. It removes the ever-present NP-comp…

> novel dependency resolution algorithm

I've heard/read this, but I can't tell what is necessarily novel about it...to me, it reads like old-school/boring Maven transitive dependency resolution.

(Not holding out maven as best practice, it's just what I know best in terms of pre-version ranges, pre-lock file dependency management, once those features become state of the art in ~2010.)

...that said, Maven does actually support version ranges; ~10 years ago when I last used it, either it didn't support them then, or we didn't use it, so perhaps that is why vgo seems so familiar. Or I just have a terrible memory.

Anyway, if anyone can correct me on my fuzzy assertion that "vgo is like maven w/fixed versions", I'd appreciate it!

Re: Taking Go modules for a spin

#34

Post by lclarkmichalek »

irq-1 wrote: post #30

Go is forever changing the pathing and configuration. Even here we have: > Very nice, go build ignored the vendor/ folder in this repository (because we’re outside $GOPATH) and > Oddly these are stored in $HOME/go/src/mod not the $GOCACHE variable that was added in Go 1.10 Maybe Go 2.0 will be stable.

I mean, the point of modules is to get rid of vendor. And if you were building outside of GOPATH previously, you were likely broken (or using a specialized build tool that handled this for you). The second one is because it's a cache. Storing them there isn't a breaking change, it's just a bit odd

Re: Taking Go modules for a spin

#35

Post by leadhyena »

pinkgodzilla wrote: post #24
benesch wrote: post #12

Earlier quoted context omitted.

I can't speak to this with absolute certainty, but I have some speculation to offer. The story of GOPATH is tightly intertwined with the story of package management. Go is a Google project, and Google has a very unique approach to package management: commit everything to the monorepo. The GOPATH is, in essence, a monorepo. If you want to change the API of a library, well, you can just change all its callers across yo…

Can someone help me understand why people hate gopath? We have a script called govars.sh at the root of every project and it sets the gopath exactly the same way one would use virtualenv in Python. We remove the default one from .bashrc or .profile. This basically makes gopath disappear entirely - we never bother explaining to new devs what it "really" means. Just ask them to use our template project folder structure…

In my experience, it's a real pain to get golang projects to build in Jenkins, and it's probably the same for any CI/CD setup, simply because of the gopath. Jenkins agents expect to set up its build directories a very particular way, and so does go with its GOPATH. Juggling it just right to get it to work is frustratingly difficult.

In fact, the one main reason I'm looking forward to this release is because of the elimination of GOPATH. It'll make my day-to-day operations at work FAR easier.

Re: Taking Go modules for a spin

#36

Post by majewsky »

weberc2 wrote: post #19
azhenley wrote: post #16

I recently started to learn Go and everything has gone smoothly... except the bizarre, unfriendly GOPATH and forced project structure. It was not fun when VS Code (with the Go plugin) would automatically remove my imports every time I saved the file because it couldn’t find it.

I like the consistent, sane project structure, but GOPATH is an odd duck to be sure.

I actually started using the GOPATH structure for all my repos after discovering three full checkouts of github.com/torvalds/linux [1] on my drive.

[1] I know it's not the official upstream remote, but I find this one the easiest to remember.

Re: Taking Go modules for a spin

#37

Post by majewsky »

lclarkmichalek wrote: post #34
irq-1 wrote: post #30

Go is forever changing the pathing and configuration. Even here we have: > Very nice, go build ignored the vendor/ folder in this repository (because we’re outside $GOPATH) and > Oddly these are stored in $HOME/go/src/mod not the $GOCACHE variable that was added in Go 1.10 Maybe Go 2.0 will be stable.

I mean, the point of modules is to get rid of vendor. And if you were building outside of GOPATH previously, you were likely broken (or using a specialized build tool that handled this for you). The second one is because it's a cache. Storing them there isn't a breaking change, it's just a bit odd

> you were likely broken (or using a specialized build tool that handled this for you)

Or you're using the isolated-GOPATH trick.

  $ mkdir -p .gopath/src/github.com/foo
  $ ln -s ../../../.. .gopath/src/github.com/foo/bar 
  $ GOPATH=$PWD/.gopath go install github.com/foo/bar
For example, this is one of my Go projects where you can unpack the release tarball anywhere and `make && make install` just works: https://github.com/sapcc/swift-http-import

Re: Taking Go modules for a spin

#38

Post by flurrything »

dilap wrote: post #28
weberc2 wrote: post #18

Earlier quoted context omitted.

Can you elaborate on why it’s easier to reason about than Cargo et al? I’ve heard a lot of theoretical criticism of Go modules for not taking Cargo’s approach so I’m surprised to hear an experience report to the contrary.

From cargo's source: "Actually solving a constraint graph is an NP-hard problem. This algorithm is basically a nice heuristic to make sure we get roughly the best answer most of the time." ( https://github.com/rust-lang/cargo/blob/master/src/cargo/cor... ) vgo's more-constrained specification for dependencies means there is exactly one right answer, and it can be easily and quickly calculated by both computer and hum…

Is there a catch to vgo's approach? If not, why aren't the cargo people copying it?

Re: Taking Go modules for a spin

#39

Post by codezero »

flurrything wrote: post #38
dilap wrote: post #28

Earlier quoted context omitted.

From cargo's source: "Actually solving a constraint graph is an NP-hard problem. This algorithm is basically a nice heuristic to make sure we get roughly the best answer most of the time." ( https://github.com/rust-lang/cargo/blob/master/src/cargo/cor... ) vgo's more-constrained specification for dependencies means there is exactly one right answer, and it can be easily and quickly calculated by both computer and hum…

Is there a catch to vgo's approach? If not, why aren't the cargo people copying it?

I’m no expert, and I might even be very wrong, but I read the post about it and it seems to hinge on only resolving a minimum version and assuming all future packages with the same import path are backwards compatible. If I’m reading right it basically treats path/to/package and path/to/package/v2 as entiresly different packages.

Re: Taking Go modules for a spin

#40

Post by civility »

flurrything wrote: post #38
dilap wrote: post #28

Earlier quoted context omitted.

From cargo's source: "Actually solving a constraint graph is an NP-hard problem. This algorithm is basically a nice heuristic to make sure we get roughly the best answer most of the time." ( https://github.com/rust-lang/cargo/blob/master/src/cargo/cor... ) vgo's more-constrained specification for dependencies means there is exactly one right answer, and it can be easily and quickly calculated by both computer and hum…

Is there a catch to vgo's approach? If not, why aren't the cargo people copying it?

As a rule, Rust and Cargo developers aren't satisfied with something until it's difficult to explain and complicated to implement.
Post reply on HN