Re: Is Guix suitable for large monorepos?

[Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>]

Am Donnerstag, dem 21.07.2022 um 23:55 -0500 schrieb jgart:
> Is Guix suitable for large monorepos?
> 
> How does Guix compare to pants in the python arena?
> 
> https://yewtu.be/watch?v=p4stnR1gCR4
> https://www.pantsbuild.org/
In my humble opinion, Guix is somewhat antithetical to monorepos.  At
the very least, the repo containing all your guix recipes is probably
distinct from the (many) repo(s) you pull your code form.  That said,
Guix can handle monorepos in multiple ways.  

You can split the monorepo into its constituent parts and build the
individual packages.  Examples, where this is "natively" supported
include GStreamer and clang, which also ship as separate tarballs.  An
example, where we do this from hand would be TeXLive.

You can also build the entire monorepo if your monorepo supports that
(just because you have a monorepo doesn't mean that it actually
builds).  Again, TeXLive is an example where we can do that.

Some comments to the video you've posted.
10:33 "How do you know who all the consumers of repo A even are?"
Well, if you have a working package manager (like Guix), you can
recursively check dependencies, e.g. using `guix refresh -l A'.
10:53 "How do I test the change?"
`guix build' already does the entire build for you.  Now granted, that
takes longer than checking the repo out yourself and running configure,
make, etc., but it'll work.
11:34 "Do the whole thing over again."
Well, Guix can help that with CI, but more importantly, there is
nothing you can do to not do the whole thing over again, even in a
monorepo.  No matter what Benjy claims to the contrary, he's either
wrong or (intentionally or otherwise) misrepresenting the cascade.
12:03 "This isn't very nice."
That's why you write ChangeLogs and guidelines for changing stuff?
13:36 "Breakages are immediately visible."
Breakages in Guix are visible once you (or CI) builds all the dependant
packages.
13:43 "... if you are scrupulous about running tests ..."
Are you really going to run all the tests from hex0 to node whenever
you flip a bit?  Chances are no.
13:55 "Codebase architecture enforces good teamwork and responsibility"
Probably maybe.  But rather than having "good teamwork" (a social
problem) and "responsibility" (a social problem) forced upon my team,
I'd rather have the team arrive at good teamwork without a monorepo
overlord.
14:09 "Monorepos can often be more flexible"
Flexibility is not inherently good.
14:49 "I have found, I have seen from experience without naming names,
that the codebase architecture is often a reflection of the structure
and function of your organization"
Don't tell him about Conway's Law.
15:10 "An engineering organization is not a bottom-up kind of thing"
(X) Doubt.
15:18 "In a well functioning engineering team, priorities and decisions
and effort allocation flow top-down"
(X) Doubt.
15:24 "Some sort of top-down organization is required"
(X) Doubt.
15:34 "... and I think this is why many large companies [...] have
adopted this monorepo architecture"
No, it's not.  It's because they are large, hierarchically structured,
top-down companies.  See Conway's Law.
17:38 "One is do less of it, and the other is do more of it
concurrently."
Good thing that Guix does both.

For pants themselves, I don't think I can take them seriously.  Not
just because I prefer skirts, but because merely looking at their repo,
I see a corporate hellhole with at least 4 kinds of lockfiles.  Are
these the people who you would trust to have valuable takes on
dependency management?

Cheers