4 ms·

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 a

by kjksf 11y ago

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.

stock_toaster 11y ago
> 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.
- 0x74696d 11y ago
  > 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. You've summed up the entire reasoning behind my post more succinctly than I could. Thanks.
Profan 11y ago
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?
shurcooL 11y ago
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.
deleted 11y ago
[deleted]
DAddYE 11y ago
This is the problem with most of the Go community: Blind. There are plenty of tools that works quite well: bundler, cargo (even with some young rough edges) and at some degrees npm. So there are tools and better ways to do it. It is just that Sir. Pike doesn't like them and Google doesn't need them. > 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. The reason why there are plenty of them is just one: none of them works well. Exact opposite of what you said. You don't have such mess of pkg managers in others languages.
- Dobbs 11y ago
  `go get` and `godep` have been excellent for us. It does everything we need it to and have had no issues. It has had far less issues than bundler, npm, etc.
  - DAddYE 11y ago
    I really doubt that. I always had problem with godeps at the point that I hate it. Right now for example I have a giant repo with tons of dependencies and: godep: unable to detect version control system for code.google.com/ path Which dependency? Tried some and they work. -__-
munificent 11y ago
> 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?

by kjksf 11y ago

stock_toaster 11y ago

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

0x74696d 11y ago
> 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. You've summed up the entire reasoning behind my post more succinctly than I could. Thanks.

Profan 11y ago

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?

shurcooL 11y ago

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.

deleted 11y ago

[deleted]

DAddYE 11y ago

This is the problem with most of the Go community: Blind. There are plenty of tools that works quite well: bundler, cargo (even with some young rough edges) and at some degrees npm. So there are tools and better ways to do it. It is just that Sir. Pike doesn't like them and Google doesn't need them. > 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. The reason why there are plenty of them is just one: none of them works well. Exact opposite of what you said. You don't have such mess of pkg managers in others languages.

Dobbs 11y ago
`go get` and `godep` have been excellent for us. It does everything we need it to and have had no issues. It has had far less issues than bundler, npm, etc.
- DAddYE 11y ago
  I really doubt that. I always had problem with godeps at the point that I hate it. Right now for example I have a giant repo with tons of dependencies and: godep: unable to detect version control system for code.google.com/ path Which dependency? Tried some and they work. -__-

munificent 11y ago

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