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

21–30 of 86 posts

Re: Problems with Go Get

#21

Post by munificent »

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.yaml file to list your package's immediate dependencies and the version ranges you allow for them.

2. You run "pub get". It finds all of your transitive dependencies, picks versions that satisfy the constraints, and downloads them.

It also creates a pubspec.lock file that specifies which versions it picked for everything. You check that into source control and now everyone on your team will use the exact same versions of all of your package's dependencies.

3. When you want to get a new version of a dependency, you run "pub upgrade ".

4. To add or remove a dependency, just edit your pubspec.yaml file then run "pub get" again.

We have a central repository where packages or hosted, and you can also pull in packages from Git or your local file system.

Packages do not at all interfere with each other. Two packages on your machine can use different versions of the same dependency without any problem.

Bundler is an absolutely brilliant package manager. My prediction is that every language either has a Bundler-style package manager or will eventually move to one.

Re: Problems with Go Get

#22

Post by kjksf »

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 getting rid of intermediary and going straight to the source.

go get has never claimed to be versioning solution so while I understand why people make shallow comparisons to pip/npm/cpan and assume that it does and complain that it does it badly (including this article), the reality is that go get is not a versioning tool at all.

There are good reasons why versioning is not supported by default in go: there isn't one way of doing it that is clearly superior to other ways. That's why we have so many solution (including the one advocated by this article) and none of the solutions became a de-facto community standard.

In summary: stop complaining that go get doesn't do versioning. There are plenty of working versioning solutions to choose from, pick the one you like the best.

Re: Problems with Go Get

#23

Post by rhodysurf »

thruflo wrote: post #17

It's a meta point but the semantic of `go get` is so beautiful I'm profoundly disappointed that the tool isn't usable. Being able to dispatch a co-routine with `go ...` is beautiful. Being able to fetch a dependency with `go get` is just as succinct and expressive. I'm not up on Go language development but imho the world would be a better place if they could fix the behaviour to preserve the syntax!

It isnt usable? Thats really an overstatement.

Re: Problems with Go Get

#24

Post by stock_toaster »

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…

  > go get has never claimed to be versioning solution so
  > while I understand why people make shallow comparisons
  > to pip/npm/cpan and assume that it does and complain that
  > it does it badly (including this article), the reality is
  > that go get is not a versioning tool at all.
The claim is that by not also solving versioning, go get is an incomplete tool. Stating that it was never intended to solve versioning is kind of beside the point.

Re: Problems with Go Get

#25

Post by Profan »

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…

The problem is that there's no reason why it couldn't also do versioning, in fact it would be sane if it did versioning, the fact that it doesn't just makes go get look like a glorified git clone.

I'd like to hear these "good reasons" why it doesn't though, what are they exactly?

Wouldn't a common standard on these things be brilliant and totally in line with go's overall philosophy?

Re: Problems with Go Get

#26

Post by shurcooL »

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…

Very nicely put, I agree.

Also, the author says:

    > go get fetches dependencies, and their dependencies,
    > and so on. But it doesn’t help you to figure out what
    > you’ve got. You can’t do the equivalent of a pip list.
You can do go list -f '{{join .Deps "\n"}}'.

Go has so few commands and options that it's easy to be familiar with all of them.

Re: Problems with Go Get

#27

Post by andrewchambers »

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

I think something like this combined with the new gb project tool would be a good solution.

Re: Problems with Go Get

#28

Post by lobster_johnson »

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

Bundler is among the better package-dependency management solutions.

I do wish Bundler would simply be bundled into Ruby at this point; it's become so ingrained that there's no longer any reason to not make it a first-class citizen. The one big problem with Bundler is "bundle exec", which is required because project-local gems can conflict with system-wide gems. If all of Ruby honoured Bundler, we could let the Ruby runtime itself handle the gem isolation.

My main complaint about Bundler and RubyGems (and NPM for that matter) is that we're still unpacking packages with no good reason. RubyGems would be easier to deal with if you could just treat .gem files like Java does with JAR files. (The sore point is gems requiring compilation of binaries, but that's solvable.)

Actually, I have another complaint: Even after numerous security gaffes, gems still generally aren't signed.

Re: Problems with Go Get

#29

Post by stock_toaster »

Seems like the author is suggesting something very similar to what [gpm][1][2] provides. I use gpm for a few projects, along with a makefile that creates a GOPATH at $(pwd)/_build, and it works fairly well.

[1]: http://java.dzone.com/articles/why-gpm-right-go-package

[2]: https://github.com/pote/gpm

Re: Problems with Go Get

#30

Post by RickHull »

lobster_johnson wrote: post #28
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.…

Bundler is among the better package-dependency management solutions. I do wish Bundler would simply be bundled into Ruby at this point; it's become so ingrained that there's no longer any reason to not make it a first-class citizen. The one big problem with Bundler is "bundle exec", which is required because project-local gems can conflict with system-wide gems. If all of Ruby honoured Bundler, we could let the Ruby…

There is a long-term plan, I believe, to merge all necessary bundler features into rubygems. Much of this has already taken place, as rubygems has (generic) support for Gemfile and Gemfile.lock
Post reply on HN