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

71–80 of 86 posts

Re: Problems with Go Get

#71

Post by TheDong »

nulltype wrote: post #66
TheDong wrote: post #64

Earlier quoted context omitted.

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?

Path rewriting means you're distributing modified copies of code, which puts you under significant legal obligation in some cases.

npm is amazing for javascript, but terrible for compiled languages and is especially terrible for security updating; the giant mess of transitive dependencies of the same dependency of varying versions can get messy fast.

Re: Problems with Go Get

#72

Post by threeseed »

0x74696d wrote: post #56
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…

> now I have to check what VCS feature it uses, wether it uses a shell script, make , or build tool Z to fetch dependencies The core of my work is on the operations side rather than on development (although I do a good bit of that as well), so my perspective is that this initial overhead is a one-time cost for using a library, and that I can live with that. > I think it's time go devs acknowledge the fact that there…

It's not a one time cost though. Whenever you have options you will have projects jumping and forth between different build tools.

This was a frequent occurence on the JVM platform as libraries moved from Ant to Maven to Gradle over the years.

Re: Problems with Go Get

#73

Post by threeseed »

barsonme wrote: post #63
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…

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…

> What happens when you can't `go get` a library because internet dies/repository moved/etc.

You cache the libraries in a central repository like Nexus or Artifactory and back it up.

This is standard practice in enterprise development where everything is restricted from downloading software except for this particular server.

Re: Problems with Go Get

#74

Post by hittaruki »

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 of the thing Cheney says in his talk about gb is that nobody likes the .lock files[1], I see that dart is using .lock files, bundlers also uses .lock files as does rust.

But other languages seems to get away without it.. clojure with lenigen seems to do it nicely.

So what are the problems with it?

http://go-talks.appspot.com/github.com/davecheney/presentati...

Re: Problems with Go Get

#76

Post by Nullabillity »

hittaruki wrote: post #74
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 of the thing Cheney says in his talk about gb is that nobody likes the .lock files[1], I see that dart is using .lock files, bundlers also uses .lock files as does rust. But other languages seems to get away without it.. clojure with lenigen seems to do it nicely. So what are the problems with it? http://go-talks.appspot.com/github.com/davecheney/presentati...

Maven-style dependency managers (including leiningen) just contain the locks inline in the regular build script.

Re: Problems with Go Get

#77

Post by nrser »

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 great. i really wish it worked for most major languages. switching between projects in different languages with different packaging systems is a bunch of weight i don't want to have to carry around or time i don't want to waste.

it sounds like you some-what 'ported' bundler to dart... what's your impression of how difficult it would be extend a tool like this to work for many languages?

it seems like i'm always asking them all to do the same thing... go get this at that version from there, include anything it needs, and stick that somewhere this thing can find it.

Re: Problems with Go Get

#78

Post by Jweb_Guru »

hittaruki wrote: post #74
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 of the thing Cheney says in his talk about gb is that nobody likes the .lock files[1], I see that dart is using .lock files, bundlers also uses .lock files as does rust. But other languages seems to get away without it.. clojure with lenigen seems to do it nicely. So what are the problems with it? http://go-talks.appspot.com/github.com/davecheney/presentati...

A slight tangent, but as someone who is sort of in the "respect but do not use" Clojure category, Leiningen seems pretty amazing. I really hope future language package managers look to it for inspiration; it seems to get practically everything right.

Re: Problems with Go Get

#79

Post by lobster_johnson »

pjungwir wrote: post #69
lobster_johnson wrote: post #28

Earlier quoted context omitted.

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: https://rvm.io/integration/bundler

Interesting. That hack is not RVM-specific (I use rbenv), but it looks like it has been superceded by the use of RUBYGEMS_GEMDEPS in RubyGems >= 2.4. If you do:

    export RUBYGEMS_GEMDEPS=-
then all binstubs will apparently be looked up via the Gemfile.

Re: Problems with Go Get

#80

Post by DAddYE »

Dobbs wrote: post #67
DAddYE wrote: post #36

Earlier quoted context omitted.

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.

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. -__-
Post reply on HN