go-dependency-position-statement.md

Hello,

Peter Bourgon recently announced his proposal for a working group of 4-6 individuals to address the need for an official dependency management solution for Go. With the imminent release of Go 1.7 and the commencement of the next development cycle, the formation of this working group should be a high priority item.

I would like to be nominated to be part of this working group and seek your support. In doing so I wish to make clear my position that, if nominated, I would represent to the working group:

• Simple. The solution must be simple in both implementation and use. It should do no more than the absolute minimum required to satisfy the requirements for a tool, and those requirements should be expressed as user stories for the various users of a Go dependency management tool.
• Opinionated. The solution will recommend and support only one way to use it. There will be an absolute minimum, and preferably no, modes, flags, or special features. It should work well for the 90% use case even if that means that some of the remaining 10% is not possible.
• SemVer. If it is decided that the recommendation of the working group is a tool that assists Go developers to resolve dependency conflicts mechanically, that solution will be based on the application of the SemVer 2.0.0 standard. To be clear, I am not advocating for or against automatic conflict resolution, that will be decided by user research.
• Actively avoid excessive dependencies. Many of the tools from competing languages make it easy (and arguably reliable) to build applications that consume upstream dependencies. However, those tools often make it easy to construct applications with enormous dependency graphs. I feel this is a problem and that Go programmers should be aware of the amount of code their product depends. Any proposed solution should not hide this cost from the end user.
• Library authors will not be second class citizens. The current vendor/ and gb solutions target Go developers building products in Go to the point that those solutions cannot be used for Go developers building libraries for others to consume. Any proposed solution must make the library author a first class citizen.

Thank you for your support.

Dave Cheney

👍 not only simple, stupid simple !

The current vendor/ and gb solutions target Go developers building products in Go to the point that those solutions cannot be used for Go developers building libraries for others to consume.

Err...could you please amend this? gb doesn't make libraries first-class citizens, but glide does.

Mostly 👍 other than that, though.