4 ms·

People who like multirepos are always saying how easy it is to pin dependencies but like you I haven’t seen anyone doing it right since I left Google. The monor

People who like multirepos are always saying how easy it is to pin dependencies but like you I haven’t seen anyone doing it right since I left Google. The monorepo third-party system works well in practice. Ps thanks for getting scipy into third_party all those years ago.

draw_down 8y ago
What’s really strange is how many people in that recent monorepo discussion were advocating for it in the context of a small org. I’ve only encountered monorepo in a large org, where I’m pretty convinced it’s more efficient than the alternative.
pjc50 8y ago
> The monorepo third-party system works well in practice. It's worth noting that this is only viable at Google because they don't use git. Git's insistence on every client having a full copy of all history of every file in the repository makes monorepo much more expensive. I see conflicting reports over whether google use Perforce or something proprietary called "piper"?
- detaro 8y ago
  AFAIK they used perforce in the past and then built their own later.
- alexhutcheson 8y ago
  This paper has details and history regarding Perforce and Piper: https://ai.google/research/pubs/pub45424 https://ai.google/research/pubs/pub45424
- anonymouzz 8y ago
  Afaik it's a custom system with download-and-cache-on-demand. Note that there's nothing forbidding you from writing a virtual git filesystem that fetches objects from some centralized repo as files are open()ed. Git on cloud steroids.
  - chokolad 8y ago
    Microsoft actually had done it and pushed the whole Windows repo into git. https://github.com/Microsoft/VFSForGit https://github.com/Microsoft/VFSForGit
- pacala 8y ago
  FWIW, there is [used to be?] a git interface for the centralized monorepo. Really handy for managing multiple dev braches at the same time.
- monocasa 8y ago
  Vfsforgit let's you do that
- sangnoir 8y ago
  > Git's insistence on every client having a full copy of all history of every file in the repository makes monorepo much more expensive. You might be happy to know Microsoft created a Virtual File System for Git[1] [2] so you do not have to have every file checked out in your working directory. Microsoft uses Git in a monorepo (for Windows, and it's 2.5 million files/300GB[2]) 1. https://github.com/Microsoft/VFSForGit https://github.com/Microsoft/VFSForGit 2. https://vfsforgit.org/ https://vfsforgit.org/
- dekhn 8y ago
  I used a git wrapper for google3 repo. It wasn't great. There are a number of semantic differences between piper/perforce and git that made it awkward. Especially code review- git doesn't handle code review well (I still find this to be an issue with github and other sites that have code review). but it was not an officially supported solution and I believe the replacement for it is based on another DVCS, Mercurial, for some silly software engineering reasons I don't like.
  - shereadsthenews 8y ago
    I used the git wrapper for a few days until I hit a day-ending `git gc`. That's when I knew git was terrible.
- jkaplowitz 8y ago
  They used to use Perforce and then actually outgrew it (!), implementing an initially backwards-compatible backend called Piper. (It may still be backwards-compatible, but it's been years since they turned off the last real Perforce and I haven't worked there for years myself. So it may have diverged.)
pacala 8y ago
Pinning dependencies is easy, and gets one stuck on Java 1.3 and IE 6. Since the library maintainer doesn't know it broke dependent code, the dependent code will be unlikely to have a smooth upgrade path. It's just a matter of having the luxury of picking up a time to pay the cost of dependency upgrades. Which cost may be high in a world where your dependencies also pin dependencies, likely at different versions. The underlying assumption it that the project will fold in 2 years anyways, so one may get away with never doing dependency upgrade.
- alexis_fr 8y ago
  That’s a good point. Do we have any solution from companies who use git/multirepos for their libraries? Is there anyway to compile refactored libraries against existing code?
  - detaro 8y ago
    For various public package managers, there's tools that automatically send e.g. a GitHub PR for an updated dependency file when a dependency updates, which then is tested by CI. I guess something like that could be made for private repos and test versions of packages too, reporting back to the authors of the dependency.
willnorris 8y ago
And for anyone that wants to learn more about how Google manages third-party code, all of our docs are public at https://opensource.google.com/docs/thirdparty/ https://opensource.google.com/docs/thirdparty/
mlthoughts2018 8y ago
I think the problem is more just a reversal of perspective. It’s up to each different app to detect and respond to a breaking change from a dependency. The idea of wanting to make a change to a third party library and then see all the downstream consumers who would be broken by that change if they updated to start consuming that change is an incredibly stupid thing to want, and it’s no measure of success whatsoever to build something that gives you that information. It’s like the most giant case of coupling you can imagine (letting the statuses of thousands of consumer apps act as any type of constraint on the developer choices of the third party library, as opposed to all those consumer apps opting in to changes on their own terms by updating their dependencies). Imagine if I have shared a bunch of copies of my resume with a bunch of recruiters. They are out there selling me as a candidate or whatever. Now I decide I want to change my resume, but I don’t know if it’s going to upset the approach some recruiter is taking. If I can’t update my resume unless I first consult a big oracle that tells me which recruiters will be negatively impacted, that’s a problem, and not at all some type of live-with-able “customer service” positive thing. It’s just plain old bad coupling. Creating such a system that could automatically diff the old resume’s usage constraints against my proposed changes would be a gigantic waste of time. The exact opposite of something to celebrate. I say this as someone who routinely writes in-house software libraries used by dozens or hundreds of other apps, various teams, and even a few that are open source. The primary thing gauging the health of our development is that we are decoupled from any consumers. We are free to make whatever changes we want, and whether downstream teams would like to receive those changes is wholly an opt-in process with versioned dependencies and easy rollbacks controlled by those consumers.
- idontpost 8y ago
  I agree in principle, but in practice its important to remember that your package only exists to be consumed by its dependencies. That is its sole purpose. If your changes aren't serving those consumers, then they're the wrong changes. It's also useful information in the edge case where consumers are relying on undocumented or unintentional behavior in your package. Yes, you don't want a hard-constraint of no-breaking changes ever, but knowing immediately when a change is breaking change (especially if you didn't intend it to be) is useful.

draw_down 8y ago

What’s really strange is how many people in that recent monorepo discussion were advocating for it in the context of a small org. I’ve only encountered monorepo in a large org, where I’m pretty convinced it’s more efficient than the alternative.

pjc50 8y ago

> The monorepo third-party system works well in practice. It's worth noting that this is only viable at Google because they don't use git. Git's insistence on every client having a full copy of all history of every file in the repository makes monorepo much more expensive. I see conflicting reports over whether google use Perforce or something proprietary called "piper"?

detaro 8y ago
AFAIK they used perforce in the past and then built their own later.
alexhutcheson 8y ago
This paper has details and history regarding Perforce and Piper: https://ai.google/research/pubs/pub45424 https://ai.google/research/pubs/pub45424
anonymouzz 8y ago
Afaik it's a custom system with download-and-cache-on-demand. Note that there's nothing forbidding you from writing a virtual git filesystem that fetches objects from some centralized repo as files are open()ed. Git on cloud steroids.
- chokolad 8y ago
  Microsoft actually had done it and pushed the whole Windows repo into git. https://github.com/Microsoft/VFSForGit https://github.com/Microsoft/VFSForGit
pacala 8y ago
FWIW, there is [used to be?] a git interface for the centralized monorepo. Really handy for managing multiple dev braches at the same time.
monocasa 8y ago
Vfsforgit let's you do that
sangnoir 8y ago
> Git's insistence on every client having a full copy of all history of every file in the repository makes monorepo much more expensive. You might be happy to know Microsoft created a Virtual File System for Git[1] [2] so you do not have to have every file checked out in your working directory. Microsoft uses Git in a monorepo (for Windows, and it's 2.5 million files/300GB[2]) 1. https://github.com/Microsoft/VFSForGit https://github.com/Microsoft/VFSForGit 2. https://vfsforgit.org/ https://vfsforgit.org/
dekhn 8y ago
I used a git wrapper for google3 repo. It wasn't great. There are a number of semantic differences between piper/perforce and git that made it awkward. Especially code review- git doesn't handle code review well (I still find this to be an issue with github and other sites that have code review). but it was not an officially supported solution and I believe the replacement for it is based on another DVCS, Mercurial, for some silly software engineering reasons I don't like.
- shereadsthenews 8y ago
  I used the git wrapper for a few days until I hit a day-ending `git gc`. That's when I knew git was terrible.
jkaplowitz 8y ago
They used to use Perforce and then actually outgrew it (!), implementing an initially backwards-compatible backend called Piper. (It may still be backwards-compatible, but it's been years since they turned off the last real Perforce and I haven't worked there for years myself. So it may have diverged.)

pacala 8y ago

Pinning dependencies is easy, and gets one stuck on Java 1.3 and IE 6. Since the library maintainer doesn't know it broke dependent code, the dependent code will be unlikely to have a smooth upgrade path. It's just a matter of having the luxury of picking up a time to pay the cost of dependency upgrades. Which cost may be high in a world where your dependencies also pin dependencies, likely at different versions. The underlying assumption it that the project will fold in 2 years anyways, so one may get away with never doing dependency upgrade.

alexis_fr 8y ago
That’s a good point. Do we have any solution from companies who use git/multirepos for their libraries? Is there anyway to compile refactored libraries against existing code?
- detaro 8y ago
  For various public package managers, there's tools that automatically send e.g. a GitHub PR for an updated dependency file when a dependency updates, which then is tested by CI. I guess something like that could be made for private repos and test versions of packages too, reporting back to the authors of the dependency.

willnorris 8y ago

And for anyone that wants to learn more about how Google manages third-party code, all of our docs are public at https://opensource.google.com/docs/thirdparty/ https://opensource.google.com/docs/thirdparty/

mlthoughts2018 8y ago

I think the problem is more just a reversal of perspective. It’s up to each different app to detect and respond to a breaking change from a dependency. The idea of wanting to make a change to a third party library and then see all the downstream consumers who would be broken by that change if they updated to start consuming that change is an incredibly stupid thing to want, and it’s no measure of success whatsoever to build something that gives you that information. It’s like the most giant case of coupling you can imagine (letting the statuses of thousands of consumer apps act as any type of constraint on the developer choices of the third party library, as opposed to all those consumer apps opting in to changes on their own terms by updating their dependencies). Imagine if I have shared a bunch of copies of my resume with a bunch of recruiters. They are out there selling me as a candidate or whatever. Now I decide I want to change my resume, but I don’t know if it’s going to upset the approach some recruiter is taking. If I can’t update my resume unless I first consult a big oracle that tells me which recruiters will be negatively impacted, that’s a problem, and not at all some type of live-with-able “customer service” positive thing. It’s just plain old bad coupling. Creating such a system that could automatically diff the old resume’s usage constraints against my proposed changes would be a gigantic waste of time. The exact opposite of something to celebrate. I say this as someone who routinely writes in-house software libraries used by dozens or hundreds of other apps, various teams, and even a few that are open source. The primary thing gauging the health of our development is that we are decoupled from any consumers. We are free to make whatever changes we want, and whether downstream teams would like to receive those changes is wholly an opt-in process with versioned dependencies and easy rollbacks controlled by those consumers.

idontpost 8y ago
I agree in principle, but in practice its important to remember that your package only exists to be consumed by its dependencies. That is its sole purpose. If your changes aren't serving those consumers, then they're the wrong changes. It's also useful information in the edge case where consumers are relying on undocumented or unintentional behavior in your package. Yes, you don't want a hard-constraint of no-breaking changes ever, but knowing immediately when a change is breaking change (especially if you didn't intend it to be) is useful.