I will only put some lights on my experience. *Gopath ect* Except at the very beginning of my experience with Go, i don't think anymore about my GOPATH. I had setup a go work space as defined by the go core team, and declared gopath appropriately. Since then, every cli project or library, I create will have its folder into the GOPATH (smthg like ~/gow/src/github.com/mh-cbon/<project>, being a gh user) Theirs dependencies will never be stored at the root of this path, they will be stored into the per project *vendor/* folder. This folder is always ignored and is automatically managed by the dependency manager tool i use, glide.
If i want to modify a dependency, i will fork it. In this case the fork will exist as a root project into my GOPATH. The projects depending on it will be modified to import the fork rather than the origin until somehow the merge to upstream occurs. *Reproducible build* To provide reproducible build, and thus manage my dependencies, i have decided to use glide because it does understand the semver mechanic and it naturally uses go engine mechanics. For each project, a file describing the dependencies exists on the root of the project. When the project needs to be built against a fresh environment, glide install command will do the necessary to fetch into the *vendor/* folder the right dependencies. According to the semver rules defined along the dependency graph. Having reproducible is an important matter, but for flexibility semver allows to declare ranges over exact version number (ie: ~1.1.1, >=1.1.1 && <1.2.0). This feature is extremely important when you depend on projects you don t maintain yourself, patches will be applied to the final product without human effort. It is also true that such behavior induces a weak contract of confidence between a provider and a consumer which do not closely work together and can lead to breakage when the provider did not respect the semver rules. (IE: publish a new version as a patch instead of a minor / major one) *Or*, if the consumer did not appropriately declared its dependency rules. To fix that instability in the dependency graph of the project a solution provided by npm was to add a new file to declare strict dependency rules based not on the latest version available, but on the version currently installed and consumed by the project (IE: lookup into the *vendor/* folder to discover the current version). Such feature must exist for production delivery system. *Diamond problem* The situation can occur, and will occur for sure. There is no ultimate solution to it. There are some situations where given the dependency tree and its semver rules, an automatic answer can be provided with no guarantee of success besides the verbal semver agreements. In case of breakage after automatic resolution, one should be able to refine the version at the root project level. Refine means to enforce a specific version range within the currently acceptable range of versions in the dependency graph. If I come to pull in a new dependency which is not compatible with the current dependency graph of my project, I will be happy the system forbids me to continue that way. *Other stuff* - So far, i never read anything about the engine compatibility. I guess, until now, we leave in a wonderful land, every go release are always backward compatible. I hope time will come where the go engine will break, for a brighter future. but, yet anyone can foresee that so far libraries and projects were not tagged to mark their engine compatibility, which will results into a more chaotic world. - Until now, go documentation was primarily focused to provide exact and precise behavioral documentation of the api. I wish some educational effort will be made to detail, explain and provide ready-to-go methodologies to setup and publish a project with the right guidance to embrace social coding (IE: a global namespace is not a good way to embrace social coding and lazy dependency). Go team has provided, what i suspect a tremendous effort, to provide a really simple and easy environment to build programs. go build and consorts are really awesome. cross platform build capability is even more awesome. go fmt is a strong and good decision. Go, as a language, is really enjoyable, as an environment to publish and share projects, it lacks some efforts. Let s hope this road toward simplicity will be continued and reach the last kilometer to provide a secure and friendly environment for social coding. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
