81–90 of 157 posts
April fool aside, what I really want is a Debian git monorepo of submodules, where each submodule points to the upstream git repository.
Why use submodules when you can properly vendor the upstream git, and export/import commits without breaking hashes on either side? https://github.com/josh-project/josh We've been using josh at TVL for years and it's just amazing.
I didn't lift an eyebrow at the headline which is apparently an april fools joke. But what is it that makes it so absurd that it works as a joke, which I'm missing? The size seems absurd (500GB) but why would the Debian source be 500GB? To me it's in no way obvious that "Debian" would include any third party packages repackaged by the distro maintainers. Are Debian people maintaining N source repositories for third p…
This includes the sources of all the Debian packages. In general this is a good idea, and it is close to how nixpkgs works (which is, in some sense, a "distributed monorepo"), but git, the Debian tooling and so on wouldn't actually be able to support a good workflow here.
Not really...? Nix distributes package definitions that describe how to build and install the package. This is close to just about every other package manager, besides the fact that most don't have / use the description on how to build the package, and instead they just download a binary based on the package definition.
The Nix equivalent to this joke would be storing all of the package code directly in the nixpkgs repo, instead of storing links to the source code. Debian would ba able to support the same flow as Nix just fine. You can just use source packages[0]
Earlier quoted context omitted.
There are real, tangible benefits to monorepos. And real, tangible downsides, too. Like everything else, it's a tradeoff. I'm sure people advocating for them have brought up some benefits. But in case they haven't, here's an example I recently encountered at work: for an application we are developing, we needed functionality X. We knew that we'd need X in other projects, too, so we made it a library. I published it t…
> for an application we are developing, we needed functionality X. We knew that we'd need X in other projects, too, so we made it a library This is the mistake: you should make it a library when you do need the functionality, not when you "know" you "would need" it.
Now I will agree that developers are often wrong. We often think something we write is important than it really is and so make it reusable when it never will be. We often think something won't be reused when it really would be. This is a hard problem, but that doesn't mean you should not think about it and work hard to get things right.
I know it‘s an April‘s fool. But I don’t get this recent trend of people arguing in favor of a monorepo (at my work place, too). It’s a nightmare to handle and use. What gives?
There are real, tangible benefits to monorepos. And real, tangible downsides, too. Like everything else, it's a tradeoff. I'm sure people advocating for them have brought up some benefits. But in case they haven't, here's an example I recently encountered at work: for an application we are developing, we needed functionality X. We knew that we'd need X in other projects, too, so we made it a library. I published it t…
Obviously you want to switch back to a release model once the feature stabilizes, to have all the advantages your internal package registry brings you.
I know it‘s an April‘s fool. But I don’t get this recent trend of people arguing in favor of a monorepo (at my work place, too). It’s a nightmare to handle and use. What gives?
A monorepo requires org changes. It requires staffing teams to handle processes and tooling for everyone else. (And it may require something else than git… but git will work OK for reasonably large ones anyway.)
I wrote about some of this here: https://jmmv.dev/2023/08/costs-exposed-monorepo-multirepo.ht...
Earlier quoted context omitted.
> Turns out, feature X wasn't as well understood as we thought it was and we are still changing things around all the time. If you publish something as a library for someone else, you should generally commit to supporting the public interface of that library as if it were a long-term support release. Exactly how long that should be depends on many factors, of course. But as a rule of thumb, I would recommend supporti…
It depends. If you drop a library for internal usage only and you want to change the contract, and the tests, library, and api are all in the same repo, you just change them in a single PR and that's done. This works because the single commit hash contains all information. It requires people put their code in the monorepo and hookup their tests, but assuming they do, you can build a reasonable degree of confidence on…
I was always surprised that Perforce didn't have anything for open source, Git is basically eating their lunch because monorepo's suck so much with git; so people do things in a more fragmented and git-friendly way. Not that I really want to see a proprietary product succeed, but it's somewhat surprising that: A) We don't have anything better B) Perforce isn't trying to gain adoption by giving its software for free t…
Maybe they should do more to highlight their strengths with regards to monorepos, but apparently their marketing hasn't identified that as a strength, or thinks it isn't a worthwhile market.
Earlier quoted context omitted.
> It’s a nightmare to handle and use Quite the opposite, IMHO. Juggling dozens of PRs across many repos for a simple change is the definition of a nightmare.
that tells me you prematurely split something. I worked at a high scale, high available system with multiple dozens of teams, each with several repos. If we had to sync changes across repos, we joined the repos because they were, well, joined. In the early days, we had shared libraries and keeping those in sync was a pita. Then we realized we should not be doing what we were doing. The flow should be: (1) update a li…
That's how you end up with infinite support costs in a large org. I think the point is that these changes are done atomically.
Earlier quoted context omitted.
There are real, tangible benefits to monorepos. And real, tangible downsides, too. Like everything else, it's a tradeoff. I'm sure people advocating for them have brought up some benefits. But in case they haven't, here's an example I recently encountered at work: for an application we are developing, we needed functionality X. We knew that we'd need X in other projects, too, so we made it a library. I published it t…
The real problems with monorepos are that most of the benefits vanish as the scale increases unless you invest into building more monorepo tooling. In your particular case, if your library becomes too popular, your one or two line implementation detail changes ripple out and trigger rebuilds of too many downstreams, many of which will have flakey tests and fail your MR. If most users are not actually depending on tha…