Mods, please rename to "Go Get Considered Harmful", as per the article's title.
Problems with Go Get
61–70 of 86 posts
Re: Problems with Go Get
#62Earlier quoted context omitted.
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.
How do you arrange to never have any transitive dependencies?
I use specific versions of libraries in my app. If two libraries depend on some third library it's rarely an issue, and when it is an issue I often have to resolve it manually anyway.
Ideally I think each library would have its own internal copy of any dependencies, but there are some issues with doing that at least in go.
Re: Problems with Go Get
#63It'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…
Seriously. What I'd like from Go is a structure where there's a source directory for my libraries (including external), a directory for the produced binaries (if any), and a text file that describes all my dependencies (including version #s). Inside each library there could be a file that provides the version # of the library.
While building the program, Go should search in my $GOPATH for the specific libraries, and if they're not found, search the libraries included with my package.
Some of the issues they've talked about included, "What happens when you can't `go get` a library because internet dies/repository moved/etc.?", which IMO is a good reason to include the libraries _with_ your Go package.
Re: Problems with Go Get
#64Earlier quoted context omitted.
How do you arrange to never have any transitive dependencies?
I use specific versions of libraries in my app. If two libraries depend on some third library it's rarely an issue, and when it is an issue I often have to resolve it manually anyway. Ideally I think each library would have its own internal copy of any dependencies, but there are some issues with doing that at least in go.
It's very easy to do that in go by just import path rewriting, ignoring legal consequences, and vendoring.
Perhaps what you want is npm where what you describe is built in, first class, and looked down upon by much of the sane world.
Re: Problems with Go Get
#65It'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!
Why is the semantic of `go get` any better than `bundle install`?
There's obviously no way they can fix the behavior in a backwards compatible way because it is so fundamentally broken, and I think that doing something because of a pretty name is absolutely ridiculous when it comes to creating a technical product. You need names like 'heartbleed' if you want to talk to management, but go get is a fundamentally developer focused tool and thus its utility should come over its naming.
I almost see its naming as a bad rap against google developers because it's an un-googleable phrase and who cares if it sounds pretty if it's un-googleable and also utterly terrible.
Re: Problems with Go Get
#66Earlier quoted context omitted.
I use specific versions of libraries in my app. If two libraries depend on some third library it's rarely an issue, and when it is an issue I often have to resolve it manually anyway. Ideally I think each library would have its own internal copy of any dependencies, but there are some issues with doing that at least in go.
It's very easy to do that in go by just import path rewriting, ignoring legal consequences, and vendoring. Perhaps what you want is npm where what you describe is built in, first class, and looked down upon by much of the sane world.
What are the legal consequences of path rewriting? And why would the sane world look down on npm?
Re: Problems with Go Get
#67While 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…
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 c…
`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.
Re: Problems with Go Get
#68I'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".
One is the shared versions as mentioned in another comment. The other one is security updates. If you release Widget that needs Gadget =1.2.3 that needs Tool =2.3.4 that needs ssl-wrapper =3.4.5 and you find out that ssl-wrapper 3.4.5 has a security issue (fixed in 3.4.6), then you can't just upgrade Widget. I would have to wait for 3 different projects to update their dependency lists to get a secure system again.
Provided that everyone does anything even resembling semver, you could just use Gadget 1.2.>=3, Tool 2.3.>=4, ssl-wrapper 3.4.>=5 instead and still be fairly sure the api won't suddenly change to something incompatible.
Re: Problems with Go Get
#69I'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…
At least in development, if you use rvm gemsets you can avoid having to type `bundle exec`. In fact I learned recently that nowadays you don't even need gemsets:
Re: Problems with Go Get
#70True story: I was in a group project in a distributed systems class, and we had made a project that relied on a go http routing package (I think it was martini or something). For some reason, my partner's computer wasn't able to present our project, so at the last minute, we cloned it to my computer. Between then and the night before, the router changed it's API, and forced us to do some crazy last-minute adjustments…
As I understood, the original idea with go gettable libraries was that:
- All releases go on master. Dev goes on separate branches.
- Do not make backwards incompatible changes.
If you need to make big changes, make another project.