This is a great article. I have also been vendorizing my dependencies. I recently have been bit by projects that I rely on (config parsers, things of that natur

This is a great article. I have also been vendorizing my dependencies. I recently have been bit by projects that I rely on (config parsers, things of that nature [and for a couple of my projects, I have too much config for using command line flags]) moving or doing silly things. The old code works fine but now it is a pain to setup a new dev environment because I have to clone from a different repo than its import path is from and check out the appropriate commits. To solve these problems I have started an experimental thing and I would love some feedback on it. I am calling it `gopkgr` and the idea to have a thing that will let you make nice tarball packages and install them.[1] Eventually, we could have something like godoc host version-ed packages. I want to be cross compatible with `go get` but I also want to support more general situations. For instance, right now it is really difficult to write polyglot go systems. In my research, I have a system that is go, java and python to tie things together. Super annoying to have such a polyglot system but I have different needs and each ecosystem offers the path of least resistance on each one of those needs. With the current go situation is not possible to create a re-usable package for the go code which is usable by other projects without breaking it out of the repo (which doesn't really make sense in this case). In anycase, I don't want to solve dependency management with gopkgr. I want to solve packaging dependencies for repeatable builds without having to worry about code moving from this source code host to that source code host. (eg. google code to github or vice versa) So if you have good ideas in this regard. Let me know about them. [1] https://github.com/timtadh/gopkgr https://github.com/timtadh/gopkgr