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

Problems with Go Get

0x74696d.com

Post reply on HN
Print view View original

41–50 of 86 posts

Re: Problems with Go Get

#41

Post by munificent »

nulltype wrote: post #37
munificent wrote: post #21

I'm awkwardly patting myself on the back here since I'm one of the co-authors, but I really wish more people knew about the package manager we have for Dart[1]. Really, though, I can't take credit, since we basically just do the same thing Bundler does. [1]: https://www.dartlang.org/tools/pub/get-started.html It solves every single one of the problems listed here. It has a very simple workflow: 1. You make a pubspec.…

One thing I've never been able to figure out about these package management systems: why do you specify a version range, and not just always specify a precise version? I don't like dependencies randomly upgrading themselves, and then you don't need "pub upgrade" or "pubspec.lock".

> why do you specify a version range, and not just always specify a precise version?

To handle shared constraints.

Let's say myapp uses foo and bar, which both use shared_thing. To solve this, we need to pick a single version of shared_thing that both foo and bar work with. If foo and bar have narrow-to-the-point-of-precise constraints like shared_thing 1.2.3+bug-fix, then it's very likely that no version of shared_thing makes both foo and bar happy. The end result is no solution.

To accommodate that, packages are strongly encouraged to semantically version themselves. Then, when you depend on a package, you use as wide a range as you can. If foo wants shared_thing ">=1.2.3 =1.3.0 <2.0.0" then the solver can pick, say, 1.5.3, and both are happy.

Re: Problems with Go Get

#42

Post by noedig »

lobster_johnson wrote: post #18

I really like the OP's structure and makefile, but it looks like a pain to work against Golang's grain here, even though the methodology makes a lot more sense to me. Maybe I have misunderstood the documentation, but what I truly, truly don't get about Go's $GOPATH is that it wants (1) my project directory to have some kind of canonical path, and (2) to pollute my project directory with dependencies. I have done a bu…

I agree with your sentiments about Java. I wish I could just have my GOPATH contain 1) the source directory for my project, and 2) one or more directories with versioned Go source tarballs for my dependencies (gar files?).

Re: Problems with Go Get

#43

Post by munificent »

kjksf wrote: post #22

While I do agree that go doesn't come with built-in solution for version pinning, this hating on go get is misguided. Most package managements solutions that are popular in other ecosystem (pip for python, npm for node, cpan for perl etc.) combine 2 functions: downloading code and versioning. go get only does the first part: downloading the code. If you ask me they solved the problem better than pip/npm/cpan by getti…

> there isn't one way of doing it that is clearly superior to other ways.

Absence of a clear winner doesn't mean doing nothing is the best strategy.

> There are plenty of working versioning solutions to choose from, pick the one you like the best.

Unfortunately, that doesn't compose.

The whole point of a package manager is to deal with acquiring dependencies and their transitive dependencies. If the ecosystem doesn't agree on a single package manager, you can't handle transitive dependencies.

What do you do when you want to use four packages, each of which uses a different package manager for its dependencies?

Re: Problems with Go Get

#44

Post by nulltype »

munificent wrote: post #41
nulltype wrote: post #37

Earlier quoted context omitted.

One thing I've never been able to figure out about these package management systems: why do you specify a version range, and not just always specify a precise version? I don't like dependencies randomly upgrading themselves, and then you don't need "pub upgrade" or "pubspec.lock".

> why do you specify a version range, and not just always specify a precise version? To handle shared constraints. Let's say myapp uses foo and bar, which both use shared_thing. To solve this, we need to pick a single version of shared_thing that both foo and bar work with. If foo and bar have narrow-to-the-point-of-precise constraints like shared_thing 1.2.3+bug-fix, then it's very likely that no version of shared_t…

Thanks for the explanation! I'm not sure I personally want to rely on semantic versioning, but if you have a hierarchy of dependencies like that I see how that would be pretty useful.

Re: Problems with Go Get

#45

Post by [deleted] »

nothrabannosir wrote: post #34
aikah wrote: post #32

It's clear to me that Go didn't get package management right,go get doesn't do package management at all. I think today it is the most important thing the go team has to solve.Otherwise, people will end up using different incompatible solutions. Projects need a manifest so that proper dependencies are declared. People who say "just use make",or "just use git submodule" or "X feature of your VCS" are just pushing for…

> I think it's time go devs acknowledge the fact that there is an serious issue here, instead of resorting to the ususal "you don't need that in go". I'm out of the loop, so honest question: does golang-dev still say that? I thought they were not in denial of the problem, but indecisive about the solution. Like with generics? Or do they consider this a non-issue? I know Cheney recently came out with his own solution,…

[deleted]

Re: Problems with Go Get

#46

Post by wallyhs »

lobster_johnson wrote: post #40
wallyhs wrote: post #33

Earlier quoted context omitted.

Instead of throwing away your project structure, try creating a "go" subdirectory in your project and setting GOPATH to point to it. Yes, you need a separate GOPATH for each project, but it's no worse than needing a separate Python virtualenv for each project.

That's what I'm doing these days. But it's painful. It means I have to run full commands such as "go install " or "go get ". To install all dependencies, I have to do "go get ". If I want to work on a project that depends on other projects that haven't been pushed to master yet, I have to clone those projects and symlink them in manually. It's pretty painful. Working with certain tools that assume a certain directory…

You omitted that from your comment, but I agree. I was just pointing out the option, because it didn't sound as if you had tried it.

I did not mean to endorse anything.

Re: Problems with Go Get

#47

Post by andrewchambers »

gecko wrote: post #39
andrewchambers wrote: post #31

Earlier quoted context omitted.

I think gb might work, but it needs to work in conjunction with a solution like ruby bundler or dart pub imo.

It does, unless I'm really missing something. Since I'm not familiar with pup, can you walk me through what of bundler's functionality you'd be missing? Maybe I just don't use bundler correctly.

gb doesn't know which ranges of versions for dependencies and transitive dependencies are compatible with each other.

Re: Problems with Go Get

#48

Post by [deleted] »

nothrabannosir wrote: post #34
aikah wrote: post #32

It's clear to me that Go didn't get package management right,go get doesn't do package management at all. I think today it is the most important thing the go team has to solve.Otherwise, people will end up using different incompatible solutions. Projects need a manifest so that proper dependencies are declared. People who say "just use make",or "just use git submodule" or "X feature of your VCS" are just pushing for…

> I think it's time go devs acknowledge the fact that there is an serious issue here, instead of resorting to the ususal "you don't need that in go". I'm out of the loop, so honest question: does golang-dev still say that? I thought they were not in denial of the problem, but indecisive about the solution. Like with generics? Or do they consider this a non-issue? I know Cheney recently came out with his own solution,…

[deleted]

Re: Problems with Go Get

#49

Post by xienze »

nothrabannosir wrote: post #34
aikah wrote: post #32

It's clear to me that Go didn't get package management right,go get doesn't do package management at all. I think today it is the most important thing the go team has to solve.Otherwise, people will end up using different incompatible solutions. Projects need a manifest so that proper dependencies are declared. People who say "just use make",or "just use git submodule" or "X feature of your VCS" are just pushing for…

> I think it's time go devs acknowledge the fact that there is an serious issue here, instead of resorting to the ususal "you don't need that in go". I'm out of the loop, so honest question: does golang-dev still say that? I thought they were not in denial of the problem, but indecisive about the solution. Like with generics? Or do they consider this a non-issue? I know Cheney recently came out with his own solution,…

> I know Cheney recently came out with his own solution, so it can't be that bad, right?

Yes, and so have others. What they really need to do is say "this is our blessed solution" and bundle it. Otherwise, there's just a bunch of competing solutions floating around and nothing is really going to take hold.

And yes I'm well aware that Java doesn't have a dependency manager but Maven emerged as the de facto way to handle dependencies. I think that has a lot to do with developer attitudes. I see Go developers as much more "don't tell me what to do, I'll roll my own solution" than Java developers, and that's why I fear a third-party dependency manager won't win out in the Go world.

Re: Problems with Go Get

#50

Post by skybrian »

"go get" works for downloading open source code to check into a monorepo [1]. This is how Google does it. But most organizations use git, which doesn't scale enough to support monorepos very well, and it's awkward if you're just using git.

[1] http://blog.rocketpoweredjetpants.com/2015/04/monorepo-one-s...

Post reply on HN