4 ms·

This is clearly detrimental to external projects such as Go packaging, since their own developers will never be looking at dependency problems in the same way a

This is clearly detrimental to external projects such as Go packaging, since their own developers will never be looking at dependency problems in the same way as outside groups. Monorepo also bugs me because there will always be some external package you need, and invariably it’s almost impossible to integrate due to years of colleagues making internal-only things assume everything imaginable about the structure and behavior of the monorepo. There will be problems not handled, etc. and it leads to a lot of NIH development because it’s almost easier in the end. Also, it just feels risky from an engineering perspective: if your repository or tools have any upper limits, it seems like you will inevitably find them with a humongous repo. And that will be Break The Company Day because your entire process is essentially set up for monorepo and no one will have any idea how to work without it.

topspin 8y ago
> This is clearly detrimental to external projects such as Go packaging Indeed. Google's monorepo means the largest cohort of Go programmers in the world are mostly indifferent to composing packages in the usual (cpan/maven/composer/npm/nuget/cargo/swift/pip/rubygems/bower/etc) manner. Non-Google Go programmers have been left to schlep around with marginal solutions for years, although in the last few months we begin to see progress here[1]. This was the #1 discouragement I experienced when experimenting with Go. Google's monorepo may be wonderful from Google's perspective but I don't think it's been a win for Go. * yes I know some of these are also build systems and provide many other capabilities, some of which are arguably detrimental. Versioned, packaged, signed dependencies and thus repeatable build artifacts is the point. [1] https://github.com/golang/go/issues/24301 https://github.com/golang/go/issues/24301
robaato 8y ago
What about Android and 800-1,000 git repos?! Have seen the pain trying to manage that across larger teams (e.g. thousands of devs) - and no the "repo" tool is not sufficient.
- nwlieb 8y ago
  I'm very curious, what pain did you see with the repo.py tool?

topspin 8y ago

> This is clearly detrimental to external projects such as Go packaging Indeed. Google's monorepo means the largest cohort of Go programmers in the world are mostly indifferent to composing packages in the usual (cpan/maven/composer/npm/nuget/cargo/swift/pip/rubygems/bower/etc) manner. Non-Google Go programmers have been left to schlep around with marginal solutions for years, although in the last few months we begin to see progress here[1]. This was the #1 discouragement I experienced when experimenting with Go. Google's monorepo may be wonderful from Google's perspective but I don't think it's been a win for Go. * yes I know some of these are also build systems and provide many other capabilities, some of which are arguably detrimental. Versioned, packaged, signed dependencies and thus repeatable build artifacts is the point. [1] https://github.com/golang/go/issues/24301 https://github.com/golang/go/issues/24301

robaato 8y ago

What about Android and 800-1,000 git repos?! Have seen the pain trying to manage that across larger teams (e.g. thousands of devs) - and no the "repo" tool is not sufficient.

nwlieb 8y ago
I'm very curious, what pain did you see with the repo.py tool?