111–120 of 166 posts
Earlier quoted context omitted.
Sounds like a tooling problem. We shouldn't use the current state of tooling as an excuse.
Isn't the entire argument about the current (or maybe "immediately foreseeable") state of tooling? We don't really care one way or the other, in a philosophical sense. What works?
Earlier quoted context omitted.
the fact that essentially 100% of big tech companies use monorepos seems like evidence that it is at least possible to do it in a scalable way...
Definitely not 100%. It also has a lot less to do with company size, and more about when the company was created. Before the git and similar tools of the world came to be, managing a single repo was a pain, nevermind hundreds or thousands of them. So (almost) everyone did it the way these big companies did. Today, not quite. I work for a multi billion dollar tech company and we have several thousand repos (and it's a…
Git cannot checkout sub directories and it slows down exponentially with the number of branches. It's the opposite of what is needed to run a mono repo in a large company.
How do the "global build tools" play with language specific build tools?
My primary stack is Rust and Scala. Both have excellent build capabilities in their native tools. How well do pants/bazel integrate with them? I wouldn't want to rewrite complex builds nor would I expect these tools to have 100% functionality of native ones.
Unfortunately some of the most popular CI/CD services out there(Travis, Circle, etc) don't even support cross-repo pipelines, much less mono repo builds.
Earlier quoted context omitted.
I want to like Bazel. I really do. But on first encounter the syntax is filled with sigils that don't seem to have obvious differences or purpose for existence. Then it turns out that I and others have spent as much time fighting it as using it. Lastly the coverage of ecosystems is sparse and there does not seem to be a lot of activity around extending them -- doing the boring, tedious, unloved work of dealing with e…
It is not a smooth experience outside of Google because the truth is bootstrapping a proper Bazel setup is not actually that easy. If you want hermetic builds for real, you need a hermetic build environment. Bazel tries to accomplish this with a workspace setup in each repo, but unfortunately it's definitely limited and imperfect. The Bazel rules for languages is also not perfect imo. Like I dislike hooking Bazel up…
Any good mono repo build tools out there? I've been thinking about this for the past few weeks. Considering creating a general purpose monorepo tool chain and potentially a mono repo first CI system. Unfortunately some of the most popular CI/CD services out there(Travis, Circle, etc) don't even support cross-repo pipelines, much less mono repo builds.
Earlier quoted context omitted.
Too slow as in "to do it" or too slow as in "to use it". In either case I think if that were true there wouldn't be monorepo's at Google, Facebook, and Microsoft. I will say it's true that didn't come for free, e.g. Microsoft had to make GVFS due to the sheer enormity of their codebase but that's already done and works pretty well. I agree share library style makes more sense in most cases though. The main problem wi…
My old boss was an engineering manager at Google in the 90s and early 2000s. He used to tell us that _everyone_ he interacted with at Google _hated_ the monorepo, and that Google’s in-house tooling did not actually produce anything approaching a sane developer experience. He used to laugh so cynically at stories or that big ACM article touting Google’s use of a monorepo (which was a historical unplanned accident base…
SVN was first released in 2000. Git in 2008. Branching, tagging and diffing were nowhere near what is possible now.
That goes back to desktop with a disk smaller than a GB, CPU in the tens of MHz with a network so slow and reliable, if you have one at all.
Earlier quoted context omitted.
> If a mono-repo has a terabyte of code, or if 10 small repos have 1/10th a terabyte each, what have you really gained? If it's a small company where every developer touches every part of the application, sure. Taking the FAANG approach if you're not part of that acronym sounds like introducing inefficiency.
If it's a "small" company then I'd expect that one Git repo would do just fine for all or at least most of the code. When I think small, I think ~10 or 20 developers. If you have reasonable hygiene about things like keeping binaries out of your Git repo (excluding consideration of e.g. LFS here) then the whole repo size will stay fairly reasonable. As long as you have one or two Git mavens on your team it should be d…
Earlier quoted context omitted.
If it's a "small" company then I'd expect that one Git repo would do just fine for all or at least most of the code. When I think small, I think ~10 or 20 developers. If you have reasonable hygiene about things like keeping binaries out of your Git repo (excluding consideration of e.g. LFS here) then the whole repo size will stay fairly reasonable. As long as you have one or two Git mavens on your team it should be d…
Sorry, what am I missing? That's exactly what I was saying - this stops making sense anywhere in between "small" and "the big boys"
Is this not saying that small companies should avoid monorepos?
Earlier quoted context omitted.
It is not a smooth experience outside of Google because the truth is bootstrapping a proper Bazel setup is not actually that easy. If you want hermetic builds for real, you need a hermetic build environment. Bazel tries to accomplish this with a workspace setup in each repo, but unfortunately it's definitely limited and imperfect. The Bazel rules for languages is also not perfect imo. Like I dislike hooking Bazel up…
Would you attribute the c/cpp success to a lack of "native" build tool?