From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id AMCFI1lO2mKK+gAAbAwnHQ (envelope-from ) for ; Fri, 22 Jul 2022 09:14:33 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id EPRuI1lO2mLyMgAAauVa8A (envelope-from ) for ; Fri, 22 Jul 2022 09:14:33 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3F2FB11AB0 for ; Fri, 22 Jul 2022 09:14:33 +0200 (CEST) Received: from localhost ([::1]:39898 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEmro-0001wm-Cl for larch@yhetil.org; Fri, 22 Jul 2022 03:14:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46946) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEmcg-00009k-NB for guix-devel@gnu.org; Fri, 22 Jul 2022 02:58:54 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:51647) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEmcd-0001Zj-MX for guix-devel@gnu.org; Fri, 22 Jul 2022 02:58:54 -0400 Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4Lq0ds4z6sz1LZXl; Fri, 22 Jul 2022 08:58:41 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4Lq0ds4z6sz1LZXl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1658473121; bh=NSRJBvCziRejcDaY0fRhNE6fxESL26DMRe9O2RCT2v4=; h=Subject:From:To:Date:In-Reply-To:References:From; b=ez11IbNknKo21fFwwMYWoCsc0+jvrYNHSmCN6Z9gpzmZvT/ShZo3sxYP5+tvXk52x AHyJP8/3K3djHhtVXUmH0yJAZ4m3b062+kXChQrAeLuIMVq+gmRHqRQBRVXXmsl1xZ 2nYq6YeTJqoncuK+Lwme4ssoRm9vDDtcVY61Ezho= Message-ID: <420e1ce118b5610881e6b86c0c4863b0339ee91d.camel@ist.tugraz.at> Subject: Re: Is Guix suitable for large monorepos? From: Liliana Marie Prikler To: jgart , Guix Devel Date: Fri, 22 Jul 2022 08:58:40 +0200 In-Reply-To: <20220721235528.GB10719@gac> References: <20220721235528.GB10719@gac> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 Received-SPF: none client-ip=129.27.2.202; envelope-from=liliana.prikler@ist.tugraz.at; helo=mailrelay.tugraz.at X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1658474073; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=NSRJBvCziRejcDaY0fRhNE6fxESL26DMRe9O2RCT2v4=; b=lOTpPHPygqRhjpdScsjbDD9uKD7Zy0pZm1/w7dq+YjGliJYAH/C4hzBMvfETEhGxve0iZ8 jntK4ecfqdUHCqhQM8eSjzpxGMx6Th6ZVSNitzaMvUPGSNUXA5PKDVAPgeYVCuvScQCoio W0jjB6j3D/To8749XpZcYVB1Vm0bmHaqwXao2+U7NB1+oEAsE0/+sbUcTKBkU9ytk2fSJ+ ArKx7Qwj1lFqt+QgQ84Q/+XZVd6KuIzxGQnpqutpCrwaYVx46qy28471akQYKGZwkD9lrd 3Z53DoBuwd2s3Dz1iFEdASVbqdjUbOalUPKcBe/BykZ6l+wWJL//eTivPtxeeg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1658474073; a=rsa-sha256; cv=none; b=Ve1INqXicCj5les8D5EBRCwE7peK6pbuZXwNJRp2t/nAPiK2oY1hkY25MBK22C0Lbsqtg5 j65XEta9j5Faio5Vax3vJU2luvzj7hAJMx6eMnvqp5/9bzAYXJIQ07CzBuxzAIpA6vnNbZ HhIVhpWJD9snBr32JGTQYUDosZbX5hmDYqyGPYmMkP8nCNxCkiTh41iOznFVPKZYkOZPYu fCrQpYA0wdqgv8lYbDgl+mJ051+tyGn2vpA1NdZcaKsvjqEAPvMLjqJW1g9id960RIb/AT 7vbi1kmnc09MGGv/7HoGlgZUUX2w7oZLi8w1osV2p1OvxpQSAQMDDJkbw2M/Ow== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=ez11IbNk; dmarc=pass (policy=none) header.from=tugraz.at; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.63 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=ez11IbNk; dmarc=pass (policy=none) header.from=tugraz.at; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 3F2FB11AB0 X-Spam-Score: -2.63 X-Migadu-Scanner: scn1.migadu.com X-TUID: MN8/r0PJRf82 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