From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id wBqhKcGp42RmlwAASxT56A (envelope-from ) for ; Mon, 21 Aug 2023 20:15:29 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id YDGLKcGp42QZHgEA9RJhRA (envelope-from ) for ; Mon, 21 Aug 2023 20:15:29 +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 5FC645D113 for ; Mon, 21 Aug 2023 20:15:29 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=G5WY+Cgw; 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"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1692641729; 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: 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=po9r2mxiq7U3WTs/WhNDFewr6x6nJo8qtbnWj63TMt4=; b=dqMzBUg4Mx4AZnAYRi52N6B1iSzdKyBTsRDhy08diaNI8jioujgGw8zYKrrgUo5TMeQ1gg PvQ9Cr6KX577uftEqiOyi+1+9icQDqY5Ys2h9eCToteJxBPq7kYEzkkxUeth3jntkyyASq Xl4R7mKWbahiI24BPtBGG+3tew2i+Snx/W4K0cvR6uHEZDC7ztqb3FqG2MRscDgYnqzHmA gGlDncq4h/Emv54u0LO0pfToNxDphRqsgfk8xCda77BqwQE+RXRvRx0KqIi4GHSJQxDWpf BtQyf7wrTKkf6sgPx+xvX3pvtFv/gMwgzBRWzAKxPQShCbhhVWg04BlgBqWWwg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1692641729; a=rsa-sha256; cv=none; b=agm7TUNZ7dbU34NzmaF7Ry6QS7/wxTtAlzC4XfCCNObHjYKlQqPbgyCY0NZQqpOPwgcfMD GONrr4B7ijxhJRe919U0YPGOpYNH/GsLwtaIpVVOWYTzYDenEfx5QJMtbVSIY2X1aoAfym IRQAXVeOGBou5NF3bOm9j0NbSr4gLX69bCNUO1PDubArxXeuLc1dwSekiEoTgHUSWiKQJx qlPkL+TFzXJAISafp9f5t/wlrqbcetho9ITyzQgOhQDUz/NsTrmIZzPVORIecVs4yllDSm fhMX4kBBaSxEsGKw/V27SzlXg0qSgWFk2lIkRw9oLFREDRiqSkT4cXJHqD5omA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=G5WY+Cgw; 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"; dmarc=pass (policy=none) header.from=gmail.com Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qY9QW-0007hI-Bk; Mon, 21 Aug 2023 14:14:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qY9QQ-0007gi-Gg for guix-devel@gnu.org; Mon, 21 Aug 2023 14:14:50 -0400 Received: from mail-il1-x12b.google.com ([2607:f8b0:4864:20::12b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qY9QN-0006Cj-W8 for guix-devel@gnu.org; Mon, 21 Aug 2023 14:14:50 -0400 Received: by mail-il1-x12b.google.com with SMTP id e9e14a558f8ab-34baf19955cso12325735ab.2 for ; Mon, 21 Aug 2023 11:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692641687; x=1693246487; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=po9r2mxiq7U3WTs/WhNDFewr6x6nJo8qtbnWj63TMt4=; b=G5WY+CgwzqNy9PmPcbkWP2IWXjix0sLN2RwaqvXS5vNd5z4R/3TSQnUCsApvdCWziV R0YG/wru6NipHwtjMkrG8si6Q3SUpahShkXVj6Ku8Dl8AvdBtbiTBccyR4cSl39/hlOC FFQdEySA75cCU8IjF4ak7P9F2nZJDBHKXdE/vu6fqKgWrvWo9cksIAaqhYDe92ZD2Z/x FKz5r49fZKmg4FW0mJK1KJoU1caYnKgfqneOmrcj1xgVCNUKPua4RNj2ICSUXDmK3Q2W Yk9tuk8d3bs8tO9M75Va9j0dopSIjeX6hNkdFGawgJvt780dL5FL+CsiwUFG9ppdIZXv X32w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692641687; x=1693246487; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=po9r2mxiq7U3WTs/WhNDFewr6x6nJo8qtbnWj63TMt4=; b=PANMbBqzSHfg7AdPAwhNK2oCCxYO3V12+D3/wXF++y+F66PCvfC1N5t04F+wK6X26e 1zJjQH70YxuPf7/q5Lfydoo4LOou/0N4LTM7qh3ox45cIHai8BY4x0ocog3XKK5H8/WW OOeev0qpdiRYYxibCLUdvg1mX2WgUCn03RKLfwFsAUAREv7Y85Kd/ZIP3UIVJ40EjJH0 OwqKYLHMCEy5g+5pfscbNxJDXWDL9ag8wpdySeZgmeFc0va6fJ5xIbFmUq6EoRUxXb5r hQ572NGqbWfteZvsfAVBBuI0/2MGnZMvEd4USQHP1vvAEhtDWhiVR2c7Eor0BfRozDqZ jHnQ== X-Gm-Message-State: AOJu0YzlXKW/lMNaoxMg+5f9CyxRJmo1BW7K8gKKzEHrBHuh12BdSouV +ujDWbJQ9B56xIgLg0sm1DrEdIo3Uzg= X-Google-Smtp-Source: AGHT+IEidr8jrKms53aMOpGvCxT2/AUDQcrbKZh88Cm3SQKa5j2O2rKcdL/kFyxp1sahPZ7uCH5wGg== X-Received: by 2002:a92:cd86:0:b0:34a:c61f:9e99 with SMTP id r6-20020a92cd86000000b0034ac61f9e99mr10155110ilb.9.1692641686643; Mon, 21 Aug 2023 11:14:46 -0700 (PDT) Received: from [10.0.2.153] (c-174-51-218-141.hsd1.co.comcast.net. [174.51.218.141]) by smtp.gmail.com with ESMTPSA id v16-20020a92c6d0000000b00345d6297aa7sm2651444ilm.16.2023.08.21.11.14.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Aug 2023 11:14:45 -0700 (PDT) Message-ID: Date: Mon, 21 Aug 2023 12:14:44 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: Updates for Go Content-Language: en-US To: Attila Lendvai , Wilko Meyer Cc: guix-devel@gnu.org References: <87jzttmi89.fsf@wmeyer.eu> <3QkPvWQ0C0OH82zm2YeBwHPjMDWunSKV0kZlRuoXre99ZZ93ng3E7kuLoeFrkXuBC_N6OlxvDmwRIoW1ryM2iLy0R3AAsk-c94mFUHyZ7oQ=@lendvai.name> From: Katherine Cox-Buday In-Reply-To: <3QkPvWQ0C0OH82zm2YeBwHPjMDWunSKV0kZlRuoXre99ZZ93ng3E7kuLoeFrkXuBC_N6OlxvDmwRIoW1ryM2iLy0R3AAsk-c94mFUHyZ7oQ=@lendvai.name> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2607:f8b0:4864:20::12b; envelope-from=cox.katherine.e@gmail.com; helo=mail-il1-x12b.google.com X-Spam_score_int: -54 X-Spam_score: -5.5 X-Spam_bar: ----- X-Spam_report: (-5.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-3.374, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.58 X-Spam-Score: -9.58 X-Migadu-Queue-Id: 5FC645D113 X-Migadu-Scanner: mx1.migadu.com X-TUID: x7Me5Oub/nSe Summary: these are good things to talk about. I think we should focus on using the current approach to get our Go ecosystem into a supported state before we talk about these things. On 8/19/23 5:31 AM, Attila Lendvai wrote: > at one point i tried to compile some large projects written in golang in a reproducible way, and making sure that they use the exact same versions of all their dependencies. > > in short: there's a philosophical mismatch between how guix and the golang crowd looks at building go apps. guix likes to explicitly represent every dependency in the guix namespace. golang has its own way of gathering the dependencies (and the nixos crowd don't mind "vendoring" the dependencies). Yeah, there's a lot of unpack in this space for sure. To repeat what I think you're saying to ensure I understand it, the way I would characterize it is that there are two concerns: 1. The version of module dependencies a module is built with 2. How the toolchain resolves dependencies (1) is not a new or unique problem to Go. Distros and software have always had mis-aligned views on what specific versions a package should use. Distros want to maintain fewer packages, and developers want to reference specific versions of dependencies. Guix is in a a better position in that it's theoretically possible to carry many different versions of the same package without conflicts. My understanding is that the limiting factor now are the resources that go into doing that (e.g. build-farms, cognitive overhead, etc.). I don't think (2) is actually a problem. A lot of projects like to "vendor" their dependencies (i.e. check in the version of their dependency in the same repository as the host module), and there's valid reasons to do that. Fortunately, Go's vendoring is strongly tied to specific versions and the code is checksummed to ensure the vendored copy isn't modified. So it follows that all Guix has to do is ignore vendored dependencies and refer to the exact same version of the Guix package. That is to say, at least the way I've framed it, I think (1) is the root of any issue that exists. > i've also worked on the golang importer (https://issues.guix.gnu.org/55242 which needs a bit more care). once it works reliably enough, then it'd be possible to import the entire transitive closure of the dependencies into an isolated namespace in guix, which would be a halfway solution between the two conflicting philosophies. Very nice! Our Go importer has improved so much, and further improvements such as these will make managing the Go ecosystem even easier. > for now i've abandoned that endeavour in favor of adding binary packages to my channel, but i made some notes on the way: > > https://issues.guix.gnu.org/43872 > > a go-build-system patch > http://issues.guix.gnu.org/50227 > discussion with iskarian > https://logs.guix.gnu.org/guix/2021-08-31.log#024401 I don't think this is an issue specifically with Go. As long as I've been involved in software, there has been an issue with N software depending on M versions of the same thing. > https://logs.guix.gnu.org/guix/2021-08-31.log#180940 > iskarian: If you search for my name and "go" or "golang" in the mailing list archives, you should find a lot of discussion > https://savannah.gnu.org/users/lfam > Here's a more recent message from me: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00227.html > Ah, I see I've unknowingly repeated you! https://lists.gnu.org/archive/html/guix-patches/2021-08/msg01222.html > Heh, it's gratifying that someone else came to the same conclusion. It means I wasn't totally in the weeds The smallest divisible unit of a Go repository that is independently distributable is now a Go module. Modules are what are resolvable, versioned, and check-summed. As a rule that may have exceptions: Guix packages should neither encapsulate anything larger nor smaller than that. Some of the messages you're referencing are right around the time modules were being reified into the Go ecosystem. I think there is an opportunity and need for Guix to try and reach a consensus on what our primitives and approaches are for the Go ecosystem and write them down in the manual. I think our current approach is workable, but there's obviously still some confusion and maybe debate to be had. Having said all of that, I think we should focus on using our current approach to get everything compiling on a supported version of Go. I think our packages and substitutes are probably carrying CVEs that have been fixed upstream, and, in my opinion, we need to resolve that ASAP. WDYT?