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 more fragmentation. I download a package.Now I have to check what VCS feature it uses, wether it uses a shell script, make , or build tool Z to fetch dependencies, do people advocating for these solutions really want to use a language where libraries aren't compatible with each others? and then some people say : just vendor and commit dependencies. Ok but let's say I find a bug in one dep. Patching all the different versions of the same dep is just not something manageable.
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".
Godeps is a first step, but we need a official way to manage packages.So everybody is on the same line.
I would really like something like composer for Go, with flat dependencies. Which means that, unlikes NPM that downloads the entire world each time one installs a library, dependencies are flat,which keeps API stables and reduce the the amount of useless libraries and forks.
> 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, so it can't be that bad, right?
> 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 is an serious issue here, instead of resorting to the ususal "you don't need that in go".
Encountering this and a lot of "well this is the way Google does is so we should too" was a big part of what inspired this post.
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.
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.
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 <package>".
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.
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.
It's a workspace layer on top of the go tool, with added support for repository pinning. You 'wgo get' the repo you want, and 'wgo {save,restore}' will pin/fetch it in the future. Also, 'wgo FOO' will do 'go FOO' with GOPATH set for your workspace, so all the normal goodness is still there.
It also makes it so you don't have to manage the GOPATH env var anymore, which I always found to be a pain.
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.
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.
> 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.
> 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?
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?
> 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.
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.
True 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. In retrospect, we probably could have manually reverted that one package's repo, but git is scary to do things with at the last second.
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.
A lot of libraries ignored the advice. Whenever a library breaks its API (sqlx for example), I stop using the library. This has made go get usable for me.
What was really difficult for me to wrap my head around was how go dependencies actually work out... via gopath, etc. My first exposure was the bash scripts for a few projects, that I was trying to build in windows... and it was to say an interesting first exposure.
I kind of wish that if go is going to use github targets for dependencies, that they at least support semver pinning and require tagging in github to support this. There are other issues, but I think that would help a lot.
It's always going to be an issue...
----
Of all the developer package managers I've used npm is probably the best... and even that has some issues.
1. Platform binaries are problematic
2. Nested hierarchies result in unexpected duplications
3. Nested hierarchies result in long paths (windows issue).
2, and 3 will be resolved with NPM3, but that brings some interesting breaking changes... beyond that is the fact that npm versions are generally pinned to node/iojs version for most.
1. I'm hoping to see a consistent implementation for tagging modules with binary dependencies, or build dependencies so that there is a build platform in place for at least common targets. Who knows if this will ever happen, and likely will be tied to paid accounts, which isn't exactly a bad thing here.
Like go get, but you specify exact versions, including transitive dependencies. One GOPATH per project. And most importantly, you don't have to use go get to install the tool in the first place.
(This isn't necessarily aimed only at blog post, but guys and gals there are other OSs supported by Go than Linux/OSX. Most of the time just having "go get" work is enough. Trust me, I've done it a lot as an outlier. I use FreeBSD and Windows.)
What's wrong with using something like party[1], or nut[2]? Or just vendoring in a way that go build still works. Seriously, what's wrong with more source files in your project's source repository?
This way I can go get your command (package main).
> Makefiles, build: docker build
Ugh, more Linux-Only. Don't follow this please.
Meh. I get your sentiment here, but I build and deploy on Linux and I post about the stuff I work on. I don't post about the Windows stuff that I haven't worked on in years. And I assume a level of intelligence in my readers that they can translate whatever might be generally applicable into their own platform in the same sense that I don't grumble about Raymond Chen's `Old New Thing` not being directly applicable to my own work but still enjoy it.
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.
Yeah, that plus gvp. But if you dig into both they're just shell scripts under the hood (nice ones, though!) and given that I've got a makefile or shell script to build the container, run tests, etc. then adding a third-party tool is just one tiny bit more overhead.
"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.
would not it be easier and cleaner to use the Android's REPO tool [1] to pin down the versions and layout your workspace?
At least the REPO allows you to write down the dependency information in a declarative manner instead of Makefile scripting snippets.
I think this is a perfect use case for `git subtree`[0]. It actually pulls everything in-repo, but can squash their history and do some other conveniences. I've always been surprised at its relative obscurity – maybe because of a terminology conflict with "subtree merges" – because it's so useful. I haven't actually used it for go dependencies, but it seems like it would be a good fit.
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 bunch of Go development and I still don't get it.
So for example, I have myproject, which I naturally want to organize in this way:
I'm supposed to work within this jungle of dependencies and generated files, in the middle of which sits my project. At least Java, for all its many faults, has the good sense to let you store dependencies nested as JAR files in a subfolder, as opposed to turning your own project into a dependency.
I have tried fixing this by symlinking my project into $GOPATH/src/whatever, but Go doesn't let me to run "go" commands on things outside the $GOPATH, which makes this rather painful to do in a shell.
Adding to the general confusion, Go doesn't manage canonical package paths, so github.com/zenazn/goji/main.go is in the package "goji" and github.com/zenazn/goji/graceful/[asterisk].go are in the package "graceful", but those package names only mean something to the importer. When "goji" wants to use the package "graceful", it imports "github.com/zenazn/goji/graceful", which, being a full URL, must be resolved from a root folder in GOPATH/src.
At least Java (for all its... etc.) had the good sense to make dotted package names mirror the folder structure of a project, not URL, thus being internally consistent. Go wants everything to live in the same sea of things. Vendoring is just half the problem.
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.
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?).
[+] [-] aikah|11 years ago|reply
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 more fragmentation. I download a package.Now I have to check what VCS feature it uses, wether it uses a shell script, make , or build tool Z to fetch dependencies, do people advocating for these solutions really want to use a language where libraries aren't compatible with each others? and then some people say : just vendor and commit dependencies. Ok but let's say I find a bug in one dep. Patching all the different versions of the same dep is just not something manageable.
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".
Godeps is a first step, but we need a official way to manage packages.So everybody is on the same line.
I would really like something like composer for Go, with flat dependencies. Which means that, unlikes NPM that downloads the entire world each time one installs a library, dependencies are flat,which keeps API stables and reduce the the amount of useless libraries and forks.
[+] [-] nothrabannosir|11 years ago|reply
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, so it can't be that bad, right?
[+] [-] 0x74696d|11 years ago|reply
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 is an serious issue here, instead of resorting to the ususal "you don't need that in go".
Encountering this and a lot of "well this is the way Google does is so we should too" was a big part of what inspired this post.
[+] [-] barsonme|11 years ago|reply
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.
[+] [-] munificent|11 years ago|reply
[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 <package>".
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.
[+] [-] lobster_johnson|11 years ago|reply
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.
[+] [-] jameskilton|11 years ago|reply
https://github.com/constabulary/gb
[+] [-] andrewchambers|11 years ago|reply
[+] [-] skj|11 years ago|reply
https://github.com/skelterjohn/wgo
It's a workspace layer on top of the go tool, with added support for repository pinning. You 'wgo get' the repo you want, and 'wgo {save,restore}' will pin/fetch it in the future. Also, 'wgo FOO' will do 'go FOO' with GOPATH set for your workspace, so all the normal goodness is still there.
It also makes it so you don't have to manage the GOPATH env var anymore, which I always found to be a pain.
[+] [-] kjksf|11 years ago|reply
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.
[+] [-] DAddYE|11 years ago|reply
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.
[+] [-] stock_toaster|11 years ago|reply
[+] [-] munificent|11 years ago|reply
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?
[+] [-] Profan|11 years ago|reply
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|11 years ago|reply
Also, the author says:
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.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] thruflo|11 years ago|reply
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!
[+] [-] TheDong|11 years ago|reply
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.
[+] [-] rhodysurf|11 years ago|reply
[+] [-] brudgers|11 years ago|reply
[+] [-] bichiliad|11 years ago|reply
TL;DR: Versioning is important.
[+] [-] papaf|11 years ago|reply
[+] [-] tracker1|11 years ago|reply
I kind of wish that if go is going to use github targets for dependencies, that they at least support semver pinning and require tagging in github to support this. There are other issues, but I think that would help a lot.
It's always going to be an issue...
----
Of all the developer package managers I've used npm is probably the best... and even that has some issues.
2, and 3 will be resolved with NPM3, but that brings some interesting breaking changes... beyond that is the fact that npm versions are generally pinned to node/iojs version for most.1. I'm hoping to see a consistent implementation for tagging modules with binary dependencies, or build dependencies so that there is a build platform in place for at least common targets. Who knows if this will ever happen, and likely will be tied to paid accounts, which isn't exactly a bad thing here.
[+] [-] joewalnes|11 years ago|reply
Like go get, but you specify exact versions, including transitive dependencies. One GOPATH per project. And most importantly, you don't have to use go get to install the tool in the first place.
[+] [-] howeyc|11 years ago|reply
Ugh, more Linux-Only. Don't follow this please.
(This isn't necessarily aimed only at blog post, but guys and gals there are other OSs supported by Go than Linux/OSX. Most of the time just having "go get" work is enough. Trust me, I've done it a lot as an outlier. I use FreeBSD and Windows.)
What's wrong with using something like party[1], or nut[2]? Or just vendoring in a way that go build still works. Seriously, what's wrong with more source files in your project's source repository?
This way I can go get your command (package main).
I dunno, maybe I'm just grumpy.
[1] https://github.com/jingweno/nut [2] https://github.com/mjibson/party
[+] [-] vhost-|11 years ago|reply
[+] [-] vezzy-fnord|11 years ago|reply
True on Docker, though.
[+] [-] 0x74696d|11 years ago|reply
Meh. I get your sentiment here, but I build and deploy on Linux and I post about the stuff I work on. I don't post about the Windows stuff that I haven't worked on in years. And I assume a level of intelligence in my readers that they can translate whatever might be generally applicable into their own platform in the same sense that I don't grumble about Raymond Chen's `Old New Thing` not being directly applicable to my own work but still enjoy it.
[+] [-] skj|11 years ago|reply
[+] [-] robfig|11 years ago|reply
The whole thing works very well at 50 developers and ~100 dependencies.
[1] https://github.com/robfig/glock
[+] [-] stock_toaster|11 years ago|reply
[1]: http://java.dzone.com/articles/why-gpm-right-go-package
[2]: https://github.com/pote/gpm
[+] [-] 0x74696d|11 years ago|reply
[+] [-] skybrian|11 years ago|reply
[1] http://blog.rocketpoweredjetpants.com/2015/04/monorepo-one-s...
[+] [-] dmitris|11 years ago|reply
[1] https://source.android.com/source/using-repo.html
[+] [-] vkjv|11 years ago|reply
[+] [-] sanderjd|11 years ago|reply
[0]: https://github.com/git/git/blob/master/contrib/subtree/git-s...
[+] [-] DrJokepu|11 years ago|reply
[+] [-] skj|11 years ago|reply
[+] [-] thelinuxkid|11 years ago|reply
[+] [-] lobster_johnson|11 years ago|reply
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 bunch of Go development and I still don't get it.
So for example, I have myproject, which I naturally want to organize in this way:
Go wants me to throw this away and structure it like this: I'm supposed to work within this jungle of dependencies and generated files, in the middle of which sits my project. At least Java, for all its many faults, has the good sense to let you store dependencies nested as JAR files in a subfolder, as opposed to turning your own project into a dependency.I have tried fixing this by symlinking my project into $GOPATH/src/whatever, but Go doesn't let me to run "go" commands on things outside the $GOPATH, which makes this rather painful to do in a shell.
Adding to the general confusion, Go doesn't manage canonical package paths, so github.com/zenazn/goji/main.go is in the package "goji" and github.com/zenazn/goji/graceful/[asterisk].go are in the package "graceful", but those package names only mean something to the importer. When "goji" wants to use the package "graceful", it imports "github.com/zenazn/goji/graceful", which, being a full URL, must be resolved from a root folder in GOPATH/src.
At least Java (for all its... etc.) had the good sense to make dotted package names mirror the folder structure of a project, not URL, thus being internally consistent. Go wants everything to live in the same sea of things. Vendoring is just half the problem.
[+] [-] wallyhs|11 years ago|reply
[+] [-] noedig|11 years ago|reply
[+] [-] jittuu|11 years ago|reply
https://groups.google.com/forum/#!topic/golang-dev/nMWoEAG55...
[+] [-] kristianp|11 years ago|reply
[+] [-] Walkman|11 years ago|reply