Are you kidding me??? So if some invariant behavior on an otherwise stable API changes, I don't know until runtime that a bunch of the code that I shipped, haven't changed, and then recompiled a month later has changed it's behavior?
Lots of people run internal Maven repos, they have every dependency vendored, but they also want the ability to choose between versions of that dependency.
[0] https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...
[0] http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-de...
The way $GOPATH works and dependencies are managed is well-documented. Everybody is free to develop their own tooling. Right now, many people flock towards godep, but that might change in the future. Also, since this is only relevant during development and for compilation, getting it right is not as important as if you had to deploy every single one of your dependencies. With Go, you get one binary, and that's what you deploy.
I've leaned towards just having everything it our DVCS (git in our case). External libraries are handled using git subtree.
There must be some standard, though. If you have neither a defined protocol, nor a defined tool, then you have a broken community. That you need to support different package managers for different Linux distros is one of the reasons people don't support Linux for their tools, and I personally would even argue that it is one of the reasons languages like Ruby, Python and Go need to solve that themselves.
Also, if you are unaware, Go has great cross-platform building. I can generate the executables for all platforms/architectures Go supports from my single dev machine.
...I don't remember reaction to that really qualifying as a fiasco, but I could just not have been paying attention at the time.
But I find it hard to believe that one person can go and fix up all the projects he's hardly ever heard of that depends on that library.
In some ways this is similar to what Linux distros do, but sharing common source control, build system, and test runner makes it easier.
Anyway, just wanted to point out that it's possible you're using Ruby lingo and not general-purpose tech terms. I could be wrong, maybe I just missed the boat.
I think "bundle everything" might make sense to everybody, including Rubyists.
http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.htm...
That's where I first read the term, but it predates svn. As far as I know, it's been the common term for committing external dependencies to your own VCS for as long as there's been such a thing as a VCS.
Vendoring means having the physical source code on hand. Not version numbers, not SHAs -- actual checked-out code.
It certainly encourages stable APIs, but I don't see how making it very painful to iterate on your API is a strategy for good ones. My experience is that doing anything well requires the ability to gather and respond to feedback. If you can't iterate, then you're doomed to be stuck at 0.0.1 levels of quality.
No, I think a language basically has to declare that level of compatibility for a major version. The important part is to get as much real-world feedback and iteration in as possible before you bang the 1.0 gong.
Q: There are several dependency management tools in the wild: godep, gpm, etc. Are there any plans to provide this functionality in the core?
Brad Fitzpatrick: We don’t want to dictate a policy, so we hope the community fights it out and a victor emerges. Then maybe we’ll bless that one. Then if everyone likes it and it has been stable for a couple of years, maybe we’ll add it to the core.
Brad Fitzpatrick: Part of the reason why we don’t care as much about dependency management inside Google is that we don’t use the go tool inside Google.
Andrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs.