From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id OK76Gbrlvl+SKwAA0tVLHw (envelope-from ) for ; Wed, 25 Nov 2020 23:16:10 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id WJTQFbrlvl+lfAAAB5/wlQ (envelope-from ) for ; Wed, 25 Nov 2020 23:16:10 +0000 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 A703F940366 for ; Wed, 25 Nov 2020 23:16:09 +0000 (UTC) Received: from localhost ([::1]:44750 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ki41A-00007t-M9 for larch@yhetil.org; Wed, 25 Nov 2020 18:16:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57656) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki411-00007b-4T for help-guix@gnu.org; Wed, 25 Nov 2020 18:15:59 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:58605) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki40z-0003mF-EU for help-guix@gnu.org; Wed, 25 Nov 2020 18:15:58 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D91905C00C5; Wed, 25 Nov 2020 18:15:56 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 25 Nov 2020 18:15:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=famulari.name; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s=mesmtp; bh=nhzmHJ3Y2d4AoGdmTiTMB2hrhBs/f4zo4O2cwYsTtrg=; b=CZlNElv3QLlb nWQ5ANkT3Uo65+VHuz8GcheGxRWQ3EUhp4s4L651sJ0tr2m4HjmxKZ1hBYn+sPnO 1u0nOE5+hHRy5l5QDMkkZCrUmeOwC6w4N2HWFL0tB2GZKNRjJFxTbZpqqOOWJhDF 6Emlqztq9kkAZ5/y+s0zJKgLZgnBa3I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=nhzmHJ3Y2d4AoGdmTiTMB2hrhBs/f4zo4O2cwYsTt rg=; b=m3BIYC9ywfd4ll6AD2GG+cALPu7J9UcOZOX9vFEQqhRlbjvusOGa/zzMu h5jE3Gj1nlDIlznDfKkRs8lO1ICCz435toIRtzvckikYzvYo5jYhNZZ/G0rEguaN I8j/ljpl5WAdFbaoHCH76Gdw+NscjKvpdKlb3t8aWTlrJGtUdHd8FItwrGdKWTa6 PoRoEjWQINZJgLI6K2BrKohs0gFkVtBhCSc4Stl5JCz8Uzq5+pRQeEZ0DJVGM5jO 1eMMpCP6OVHDLleCHJCZXpt8lv43dQXVWZ1A89ouumjdP1UhKIh+cECFhTzPDKGR oAyIf4GT4mPFbBwdydIjlz+RWpvVQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudehuddgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjsehtke ertddttdejnecuhfhrohhmpefnvghoucfhrghmuhhlrghrihcuoehlvghosehfrghmuhhl rghrihdrnhgrmhgvqeenucggtffrrghtthgvrhhnpeekheegjeetfffgheefvdefgeetke etheegleeltdffveefjeeiheevieehgeekteenucffohhmrghinhepghholhgrnhhgrdho rhhgnecukfhppeejfedrudeguddruddvjedrudegieenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehlvghosehfrghmuhhlrghrihdrnhgrmhgv X-ME-Proxy: Received: from localhost (c-73-141-127-146.hsd1.pa.comcast.net [73.141.127.146]) by mail.messagingengine.com (Postfix) with ESMTPA id 80C723280059; Wed, 25 Nov 2020 18:15:56 -0500 (EST) Date: Wed, 25 Nov 2020 18:15:54 -0500 From: Leo Famulari To: Stephen Scheck Subject: Re: Build determinism, dependency granularity, and dependency scope Message-ID: <20201125231554.GD2093@jasmine.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Received-SPF: pass client-ip=66.111.4.29; envelope-from=leo@famulari.name; helo=out5-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: help-guix Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: "Help-Guix" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=famulari.name header.s=mesmtp header.b=CZlNElv3; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=m3BIYC9y; dmarc=none; spf=pass (aspmx1.migadu.com: domain of help-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=help-guix-bounces@gnu.org X-Spam-Score: -1.21 X-TUID: z3PIjYvIwo++ On Tue, Nov 24, 2020 at 04:20:35PM -0500, Stephen Scheck wrote: > But if you look at the commits for the packages defined in the Guix tree, > they do not correspond. And the `go-golang-org-x-text` package in the Guix > tree (version "0.3.2") does not even meet the minimum version specified in > `go.mod`. Right. > Am I missing something here? No. The way that dependencies are handled in Go-world does concord with Guix on a conceptual level — it's definitely possible to have hundreds of versions of each Go library — but it's impractical with the current Guix tooling. > It seems like what is needed would something like a package-scoped > "dependency constructor", allowing you to declare required versions > per-package: > > (propagated-inputs > ;; ... > ("go-golang-org-x-net" (go-module "golang.org/x/net" "244492dfa37a")) > ("go-golang-org-x-text" (go-module "golang.org/x/text" > "929e72ca90de")) > ;; ... ) Yes, I've suggested something like this before (somewhere in the mailing list archives). The specifications would also need to include the source hash, but otherwise we've come to the same conclusion. Ideally, they would be generated automatically from go.mod. Previously, I made sure these "standard" Go libraries matched the versions specified by Syncthing, since I maintained that package carefully. Since Syncthing switched to Go modules, I haven't found the time to rework Guix's go-build-system to work correctly, and I haven't paid attention to what's been happening with Go on Guix. A good stopgap option is to use vendored dependencies (heresy, I know), assuming they are free software and the upstream sources include them. This works fine and is better than not having Go software at all. In the long run, Guix's Go support needs a complete overhaul.