Thank you, Russ! Those points make a lot of sense. >From a logistics standpoint, I'm curious if there have been successful go-monorepo code base built on top of commonly available systems (i.e. git).
Like is a Bazel system as per kubernetes <https://github.com/kubernetes/kubernetes> a generally accessable way to go? or does k8s just use it because of the legacy of Google's build system? Etcd <https://github.com/coreos/etcd> has a different build mechanism which seems to try and leverage go's builtin build system a bit more. So as far as having a single repository with a bunch of services or builds off of it, having vendored source code in the repository, and using as many "go native" build semantics as possible, etcd is a reasonable project to emulate? On Tuesday, September 26, 2017 at 7:00:14 AM UTC-7, Russ Cox wrote: > > On Fri, Sep 22, 2017 at 1:08 PM, <charle...@metamarkets.com <javascript:>> > wrote: > >> Hi all, >> >> I have a question regarding modern best practices for go repositories. As >> we are building out services in go, we still have the opportunity now to >> refactor the service code pretty dynamically. So now is a good time to >> check and see if we're growing the repositories in a reasonable way. Our >> version management system is git (github). >> >> There are two major routes I can see going down with regards to our >> organization's go code. >> >> 1. All internal code is in a single repository, and any time a >> developer wants to update an external dependency (ex: logrus or >> whatever), >> they are responsible for making sure the new version works on the rest of >> the code base by resolving function signature changes. This is closer to >> the mono-repo workflow. >> 2. All internal code resides in repositories which are split up into >> much smaller components. Each service service would be its own repository >> with its own build definitions, and the different "common libraries" >> would >> have their own repositories also. Each service lazily and independently >> updates their dependencies only when a dependency update is needed. This >> is >> closer to how the common Maven/SBT (java / scala) based artifact system >> works. >> >> Does anyone in the go community have some good suggestions or pitfalls >> regarding the above approaches? Or is there a different way that is >> suggested. >> > > Today I think the best approach is still to use a single repository as in > your (1), with a vendoring tool such as dep (or glide, as Steven Hartland > suggested) to make a local copy of the code. > > Shawn Milochik pointed out that a monorepo causes extra up-front > coordination to prevent or resolve merge conflicts, but that work usually > has to happen one way or the other. In #2 it is just taken on as debt, and > worse as debt that may not be obvious at the time. Front-loading the > coordination can help avoid taking on too much of this debt. > > In the longer term we hope to provide better tooling around all of this, > but it's not ready yet. > > Russ > -- 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.
