From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id QWJDJD8xfGAyIAAAgWs5BA (envelope-from ) for ; Sun, 18 Apr 2021 15:16:47 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id iNfMHj8xfGBJLAAAbx9fmQ (envelope-from ) for ; Sun, 18 Apr 2021 13:16:47 +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 3AB16173BE for ; Sun, 18 Apr 2021 15:16:47 +0200 (CEST) Received: from localhost ([::1]:55324 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lY7I5-0003s8-Mn for larch@yhetil.org; Sun, 18 Apr 2021 09:16:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51172) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lY4lv-0002Dg-BS for guix-devel@gnu.org; Sun, 18 Apr 2021 06:35:23 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:39953) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lY4lm-0006Pn-CN for guix-devel@gnu.org; Sun, 18 Apr 2021 06:35:23 -0400 X-Originating-IP: 88.126.13.52 Received: from localhost (unknown [88.126.13.52]) (Authenticated sender: francois@avalenn.eu) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id D90A01C0005; Sun, 18 Apr 2021 10:35:08 +0000 (UTC) Date: Sun, 18 Apr 2021 12:31:53 +0200 From: =?utf-8?B?RnJhbsOnb2lz?= To: Maxim Cournoyer , Guix Devel Subject: go-build-system possible improvments Message-ID: <20210418103153.uvxb5jlnliq3rzua@noop.avalenn.eu> References: <87eeg7vn3d.fsf@gmail.com> <20210414120939.mmvprjaz6636kz4h@noop.avalenn.eu> <87czusjtpc.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87czusjtpc.fsf@gmail.com> Received-SPF: none client-ip=217.70.183.197; envelope-from=francois@avalenn.eu; helo=relay5-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 18 Apr 2021 09:16:26 -0400 X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1618751807; 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; bh=Zzo5YjnowGDeNjxShNIFbyUsvZmOQJDkC5E83+ZgQuA=; b=N5ptJ8DqJwj7Ag1vQESkLmrkYlFE5GaABzNB7lD6H5/XW/4bIt2OIxM57gk07m9ScbnnuY g8XOZNvqNRfBNsh3Dpvzs7TuJ2X1QndPreNuk2Oa59vF5u0BibY2p2CjsR9GGhewHYD86K +FMpQJ26ESsrIft79mI35TMQqIg6lxjR4Z9GMsGuAIcCGEJcVxriw3omQ2WkDxmhA0H8uG /yu65fUHw/8c19K20XJQPQExfQyWREQj7AN7ggLIlS1suJ1JWH/HFHt+3G1Tx/vxYhXuPj 6eyhQqQJSjlZx6yDQTzEgDgqPLYb0iHq9I6UaV9LqxtFqphTXJz3qGbP3HUxUw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1618751807; a=rsa-sha256; cv=none; b=lPBeArxf6HxbeR7VNdsfUxdC+4cbcJoYMrj40fbXU7br2bAYo0K7iUhg8rGh1rjFLavIFF kx7WVbbdmT5L0bx6RePl/xrlTJ3+WP13ojG4XJyVTscsbrlVZrnm3zyBcdoezkKOG9QOIT M8X2N77j2Sb+3mxQBZzDYcYBOa9Q9htxQ2NmYgWzrYtmWWwo96aPk8z5L3XdQAeICtxg/o 1W3u26dPcYIgPHZJG/wgye1af68svTtPB0UtFWxWCNfcTbaa2ntPDKjygTOe9+2AofrgPk 8s/AcORan89TO2ZWgAHkdG01y5ldMkL9jw7RoXa8cghiTMK98FvJzVFppYZa0w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -2.44 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 3AB16173BE X-Spam-Score: -2.44 X-Migadu-Scanner: scn0.migadu.com X-TUID: MLGZ99HhfhO6 Hello, I come back to public guix-devel as I think it can be of interest to others too. On Sat, Apr 17, 2021 at 08:57:03PM -0400, Maxim Cournoyer wrote: > JOULAUD François writes: > > > I am still unsure of what to do with versions and Go but the ability to > > pin version will surely be useful in some way. > > Yeah, I was expecting it might unlock building the new protobuf package > especially a couple version backs, it had a really messy dependency > chain including past versions of itself, but it turns out that for now > the bigger problem is the lack of support for Go modules. Yes. This is the biggest lock. Supporting go modules will really unlock a lot of things. > I'm glad to hear it! I had read lots about Go and had some kind of plan > for the GOPROXY (the project doing best in this regard is Gentoo); in > theory it's possible to populate a cache with the source artifacts in a > given directory (probably via a union of the individual packages > contribution to the cache), then setup GOPROXY as a file server to > provide these at build time. I just made a lot of reading this week-end and I was more oriented towards using GOPROXY=off and populating on-disk [module cache] which have the exact same organisation as GOPROXY as it is indeed the last layer of proxying. If it works it will avoid the need for a specific local server. Concerning the former dependeency loop with google-protobuf it was (before 1.26) indeed necessary to have all go.mod files for all versions referenced recursively. Go downloads (or need to have in cache) only the go.mod files though because once it have the go.mod the [Minimal Version Selection] kicks in and keep only the higher version requested[^1]. So we could cheat by putting only go.mod files for older versions in out local cache without the need for anything else and it should work. The same thing applies to conditional compilation. Go needs the go.mod files but don't need the code itself until it tries to compiles it. So we have probably a safe way to import those packages without too many useless packages in our dependency graph even if it can require a solution to easily add specific go.mod files in our outputs. They, at Go, are nevertheless [working][lazy-loading] to modify this behaviour in order to avoid useless network calls to GOPROXY but it could not land in Go 1.15. It should be there in next release. [module cache]: https://golang.org/ref/mod#module-cache [lazy-loading]: https://go.googlesource.com/proposal/+/master/design/36460-lazy-module-loading.md [Minimal Version Selection]: https://research.swtch.com/vgo-mvs [^1]: Which seems strange until you understand that you always require a "minimal" version in Go. The minimal version needed to build a project is thus the maximum of all minimal required versions. The link explains this a lot better than me ;-) François P.S. just as writing this I found that if we want to limit the number of versions of Guix-packaged Go modules we could devise a mechanism to force upgrade (go get -u) to the latest in-Guix version. This open a lots more question to me than it resolves. P.P.S. other solution, perhaps simpler is to not support go.mod at all (GO11MODULE=off) and to populate the local GOPATH as we see fit. I think (but I am not sure) that Debian took this route. Not found of this solution, I think we have the means to do better in Guix and to keep more in touch with upstream methodologies.