From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id gBgSBSIC42JPWAAAbAwnHQ (envelope-from ) for ; Thu, 28 Jul 2022 23:39:46 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id wPwMBCIC42KJmQAAG6o9tA (envelope-from ) for ; Thu, 28 Jul 2022 23:39:46 +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 B834F14DC7 for ; Thu, 28 Jul 2022 23:39:45 +0200 (CEST) Received: from localhost ([::1]:35496 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHBEN-0004Zr-Rj for larch@yhetil.org; Thu, 28 Jul 2022 17:39:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41940) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHBDx-0004Zh-Mb for guix-devel@gnu.org; Thu, 28 Jul 2022 17:39:17 -0400 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]:41574) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHBDv-0007GV-0Q for guix-devel@gnu.org; Thu, 28 Jul 2022 17:39:17 -0400 Received: by mail-ej1-x62f.google.com with SMTP id z23so5298237eju.8 for ; Thu, 28 Jul 2022 14:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sweatshoppe-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jF0Y26QJ1mIv0SIJgqmKLgwAwzo05D0Ght73MAcnTnM=; b=LbAICTKZPc5ny4Pbtxxh7lthh8bCPb1c743HlCVpnopzpvSTLOssAxB5dNNF+11oQk CSbqKujw5ZRJ4pQXzr1Nfzlzq5/VG5P955oTmE0nDywPLSXIRaWTxdjeAo1M4k6XwfkU A3y5hi1okOydWEbGxiCJbEuDE/UgqUkScC39MWOUyVLTv0Jvc1sEQM/j8LghEcb6svU0 F/1lZcKt29uuDMboeBCe15eQOvaXEk6qczFA9QAHJy1TXlhsrpiboEoiMAQOPeDJ8D8a 0xIo7v6drh/1aqeVxZMSHizp0zQFnDseB6TS9P4ZSVD+yOyL8qhJjmv7ExjP8cufhuZn 2X1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jF0Y26QJ1mIv0SIJgqmKLgwAwzo05D0Ght73MAcnTnM=; b=GCAoPTBO9k/PNrUGGW9LxiIQGjNPehKVhDHlARAepmOZJCdFq6WLh/SNZ4lgNw7TLn r+2eH6shKyLlt7XBa1KFwxJt5SdOVlF1b4KI6xEdyN3JL5x6FsdHfgXiulpdfQfsBDTQ dQ+arxN+FxMvO35+i09bN1OkM8AunoFtY75bBzODrpJNb/aI9ZIu4q5uRqXgKfi4BwDk QGueXGLYTgXF5Orf4DNk3Oye/EIc4LbsTWRy1sfTXx5iHGKiksE9pf7sSn3twoQ1iOF0 lE3N6RrpaPUUjUS8R2A1+5M4A4Sl5f3DBJZC2nJl3xAK/tPXN6pfmpy6m1i9Kf4Iv3f+ 7rqQ== X-Gm-Message-State: AJIora+U/wHZ6YOUYCeeIFgLNaxYxWc1Yijie0zvImXmvfiqe64lBMKG sPRf4uaNTHUc6ZQcIaoBa32ZFGHiMpvV2LukhTr4rg== X-Google-Smtp-Source: AGRyM1tA0pjqo8MUucN+Spcj6oe6fBSFJ79S7VrhZGiKqRF0GExV3czcR8uk6wdZzio2FI6PyILgFrNPTKwKmy3ZWIc= X-Received: by 2002:a17:907:1c24:b0:72b:838f:cada with SMTP id nc36-20020a1709071c2400b0072b838fcadamr607317ejc.125.1659044353055; Thu, 28 Jul 2022 14:39:13 -0700 (PDT) MIME-Version: 1.0 References: <20220721235528.GB10719@gac> <87zgh1teag.fsf@gmail.com> In-Reply-To: <87zgh1teag.fsf@gmail.com> From: Blake Shaw Date: Thu, 28 Jul 2022 21:39:01 +0000 Message-ID: Subject: Re: Is Guix suitable for large monorepos? To: Katherine Cox-Buday Cc: jgart , Guix Devel Content-Type: multipart/alternative; boundary="00000000000054b51e05e4e45d2a" Received-SPF: none client-ip=2a00:1450:4864:20::62f; envelope-from=blake@sweatshoppe.org; helo=mail-ej1-x62f.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=1659044385; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=jF0Y26QJ1mIv0SIJgqmKLgwAwzo05D0Ght73MAcnTnM=; b=HDf2lDaNBOUqnDnSR2gneZiRr/nIQS6+rUNz657hLl7HPIBBfUK20d5+C32fVby4KGdKWE FkBw01jLxwUiPqIT2wNjF34shSn8/QcQlGUMGZVXemNgS1JzE6Z8PowRqxu9+GTiRhSbPc 4slOtM/jLMGn2hrK+K89AKj6TrBkhm3rWJXNJlpTQEXuv+ubsqfHk7uTjOhuAJ7QUx0bH5 DtFtBGRkplWGhynJCdKB/nsNfb2uknCWUe3wddA1m/zqttKhteqS/96dma6Uj72tmpDlIz G4mc62sQzXbmxCyaO+sfPBDlz33C1iDLk3LnjHtNWLjGsAz0fFEp5AYCYduF7A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1659044385; a=rsa-sha256; cv=none; b=JC4cOdSKSxLaMqb75vukGz/AaXRZJw1reTgQMcZJIL+WneKZxY8EGt9yM6/NDcVXb8fUGh ID3Mh0Kikt57H9n3TyGHdCaBzy5/Fi3/2/d1hKi7FWpVtKzRxJJGNSjiV4Xl5pE04VnsE2 Pfdb8RwQOEv3UNCHcLJ+8ciONi+1g5lOw8jvxRuu7darHLXeK/QJAMYO+9hvrHQfJtMsAZ jc7WjBFHa7gNHw4h0ck3A2K+minaFNGkthIlNMcgQXS6gHu5TN8JTU8kDznXG9wz8I26LN RmhCQxZ9QsaaZ4NQ9PaBavSG0sSSyyeohcqs6HqUVVkwkG2/jRE5UbWfwvevXQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=sweatshoppe-org.20210112.gappssmtp.com header.s=20210112 header.b=LbAICTKZ; dmarc=none; 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.42 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=sweatshoppe-org.20210112.gappssmtp.com header.s=20210112 header.b=LbAICTKZ; dmarc=none; 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: B834F14DC7 X-Spam-Score: -2.42 X-Migadu-Scanner: scn1.migadu.com X-TUID: QVl8/6MPRbhk --00000000000054b51e05e4e45d2a Content-Type: text/plain; charset="UTF-8" Hiya guix, I tried to reply to this quickly while I was travelling, but what started with "sorry to brief" quickly became quite long -- nonetheless I think theres some important insight into using Guix effectively in production I'd still like to share, so will finish it off now that I'm back: == I'm traveling at the moment so excuse me for being brief but I saw Katherine's message about long source rebuilds and want to try to chime in quickly. I had a difficult experience of using Guix in production against a medium-large C++ repo (openFrameworks) in June when substitute availability was failing a good deal of the time, along with several broken packages "infecting" a decent area of oF's ~140 package dependency graph, to add to the mayhem. Considering it was a moment I needed to move fast, I created a hotfix branch where I could disable tests, do quick gnarly fixes and keep moving. Its worth noting that working like this you can really knock out a lot of package "fixes" quickly, I was able to do 10 in a day, but also this was while deploying a video mapping project so security wasn't a huge concern. This initially worked decently, in terms of maintaining project momentum while racing towards a delivery. But when it came to installing on the servers and the laptop onsite, which came with their own difficulties, the build times started weighing in more than I was able to handle. I had been considering starting a Cuirass instance but was worried it would be too difficult to figure out in constrained time. At some point I thought "you know what lets try this just not sleep and see if cuirass can be a solution, and if its immediately confusing shelve it and move on". But the truth was... ...Cuirass was one of the quickest parts of the Guix system I've hit the ground running with. I really wish I had deployed it from the outset, and I surely will on all future projects. Within a day of fiddling with it I had my linode providing substitutes of not only my dependency graph, but also generations of three different systems, as well as VMs. After the first night of building i suddenly had lightning fast substitutes available and problems upstream faded away. In short, had I used Cuirass from the get-go I would have saved myself from a massive amount of difficulty. The difficulty with reproducibility in production is that it you're constrained for time, building back to a month old generation can be out of the question. I think there is a "reproducibility ideal" that we and the Nix folks often allude to as our reality, where "you just roll back", but the conditions of production can often make this unfeasible. Before my next gig I plan to automate things so that I can easily tag commits in git that will trigger system generations to be built and stored as QEMU images that I can quickly access as need, which I think will bring me closer to this ideal. I'll be sure to share when it comes time (but currently taking a little break from being deep in the weeds). Also, my apologies that I haven't been contributing much... an experiment with self-hosting my email earlier this year ended with a borked email server and I have yet to setup gnus & git with this email address. Will be rolling up my sleeves in the coming weeks :) Happy hacking! b On Fri, Jul 22, 2022, 21:26 Katherine Cox-Buday wrote: > jgart writes: > > > Is Guix suitable for large monorepos? > > I use Guix against a large mono-repo, and there are a few > difficulties. > > I should mention that I am not using Guix in the typical fashion with > fixed commits (packages are pointed at HEAD and I don't use checksums). > For my purposes, it's useful for me to build HEAD, although sometimes I > use transformation options if I'm interested in a specific branch or > commit. > > I've defined a package for the entire repo and then individual packages > for the constituent projects which inherit from the repo package. > > For new commits: > > - Updating the source take a long time. > - Indexing the entire repo takes a long time. > - Copying over the entire tree to the build directory is unnecessary and > takes time. > > Sometimes I want to build a local change I haven't committed anywhere, > so I use the --with-source option. The problems are the same, but > they're exacerbated. > > A happy medium I've landed on is to build some binaries outside of Guix > and then use packages that are defined in terms of the binaries. These > packages use patchelf to get everything linked correctly. This allows me > to reify these packages into Guix while keeping the standard workflow > from a programming language. > > I've also considered a phase that, after checkout, deletes all files not > relevant to the project to lessen the burden of copying things over for > building. > > So, in my opinion, these issues are not really Guix's fault, and it does > a pretty good job all things considered. I think Guix used in a CI/CD > pipeline (which I guess means cuirass) would handle mono-repositories > wonderfully and do exactly what I want: reproducible, verifiable, > builds. Guix as a development tool in these situations is still useful, > but has some things that make it a little difficult to work with. > > Maybe someone has some ideas to improve things? > > -- > Katherine > > --00000000000054b51e05e4e45d2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hiya guix,

I tried to reply to this quickly while I was travelling, but what starte= d with "sorry to brief" quickly became quite long -- nonetheless = I think theres some important insight into using Guix effectively in produc= tion I'd still like to share, so will finish it off now that I'm ba= ck:

=3D=3D
I'm trav= eling at the moment so excuse me for being brief but I saw Katherine's = message about long source rebuilds and want to try to chime in quickly.

I had a difficult experienc= e of using Guix in production against a medium-large C++ repo (openFramewor= ks) in June when substitute availability was failing a good deal of the tim= e, along with several broken packages=C2=A0 "infecting" a decent = area of oF's ~140 package dependency graph, to add to the mayhem.
=

Considering it was a moment I= needed to move fast, I created a hotfix branch where I could disable tests= , do quick gnarly fixes and keep moving. Its worth noting that working like= this you can really knock out a lot of package "fixes" quickly, = I was able to do 10 in a day, but also this was while deploying a video map= ping project so security wasn't a huge concern.
=
This initially worked decently, in terms of mai= ntaining project momentum while racing towards a delivery. But when it came= to installing on the servers and the laptop onsite, which came with their = own difficulties, the build times started weighing in more than I was able = to handle.

I had been co= nsidering starting a Cuirass instance but was worried it would be too diffi= cult to figure out in constrained time. At some point I thought "you k= now what lets try this just not sleep and see if cuirass can be a solution,= and if its immediately confusing shelve it and move on". But the trut= h was...

...Cuirass was = one of the quickest parts of the Guix system I've hit the ground runnin= g with.

I really wish I = had deployed it from the outset, and I surely will on all future projects. = Within a day of fiddling with it I had my linode providing substitutes of= not only my dependency graph, but also generations of three different syst= ems, as well as VMs. After the first night of building i suddenly had light= ning fast substitutes available and problems upstream faded away. In short,= had I used Cuirass from the get-go I would have saved myself from a massiv= e amount of difficulty.

The difficult= y with reproducibility in production is that it you're constrained for = time, building back to a month old generation can be out of the question. I= think there is a "reproducibility ideal" that we and the Nix fol= ks often allude to as our reality, where "you just roll back", bu= t the conditions of production can often make this unfeasible. Before my ne= xt gig I plan to automate things so that I can easily tag commits in git th= at will trigger system generations to be built and stored as QEMU images t= hat I can quickly access as need, which I think will bring me closer to thi= s ideal. I'll be sure to share when it comes time (but currently taking= a little break from being deep in the weeds).

Als= o, my apologies that I haven't been contributing much... an experiment= with self-hosting my email earlier this year ended with a borked email ser= ver and I have yet to setup gnus & git with this email address. Will be= rolling up my sleeves in the coming weeks :)

= Happy hacking!
b



On = Fri, Jul 22, 2022, 21:26 Katherine Cox-Buday <cox.katherine.e@gma= il.com> wrote:
jgart <jgart@dismail.de> writes:

> Is Guix suitable for large monorepos?

I use Guix against a large mono-repo, and there are a few
difficulties.

I should mention that I am not using Guix in the typical fashion with
fixed commits (packages are pointed at HEAD and I don't use checksums).=
For my purposes, it's useful for me to build HEAD, although sometimes I=
use transformation options if I'm interested in a specific branch or commit.

I've defined a package for the entire repo and then individual packages=
for the constituent projects which inherit from the repo package.

For new commits:

- Updating the source take a long time.
- Indexing the entire repo takes a long time.
- Copying over the entire tree to the build directory is unnecessary and =C2=A0 takes time.

Sometimes I want to build a local change I haven't committed anywhere,<= br> so I use the --with-source option. The problems are the same, but
they're exacerbated.

A happy medium I've landed on is to build some binaries outside of Guix=
and then use packages that are defined in terms of the binaries. These
packages use patchelf to get everything linked correctly. This allows me to reify these packages into Guix while keeping the standard workflow
from a programming language.

I've also considered a phase that, after checkout, deletes all files no= t
relevant to the project to lessen the burden of copying things over for
building.

So, in my opinion, these issues are not really Guix's fault, and it doe= s
a pretty good job all things considered. I think Guix used in a CI/CD
pipeline (which I guess means cuirass) would handle mono-repositories
wonderfully and do exactly what I want: reproducible, verifiable,
builds. Guix as a development tool in these situations is still useful,
but has some things that make it a little difficult to work with.

Maybe someone has some ideas to improve things?

--
Katherine

--00000000000054b51e05e4e45d2a--