From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id yH6ZFeuLFmcPTQEA62LTzQ:P1 (envelope-from ) for ; Mon, 21 Oct 2024 17:14:19 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id yH6ZFeuLFmcPTQEA62LTzQ (envelope-from ) for ; Mon, 21 Oct 2024 19:14:19 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=ngraves.fr header.s=ovhmo4487190-selector1 header.b=Vsqp1VbY; 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=reject) header.from=ngraves.fr ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1729530859; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=MeTkiwMI2cGmd7hucdKoOylrbhaujsxepqhrJi4nxFs=; b=QsoKU4K2ug6XEzobCXnYZ+s5fA5zdKNe8jzrq68INV7kZiLrwVJKqzyI7tuAh4J4kEnLUi Qns1VYCtSpFW1YFsGQ0ilsZIdmWCeXFIKscQwtPWnpjavnen6A8iClEkK/3JihAPQMlQZv y40iQbnxdcpBNbn82GEMzVujPKC9LMv+NY54OrKaBD6ygASnSuqCWXxOlB791gQ5CiDOFj 1TGeMpGOOFTtcQqxJNPFte3MJNVbLjVVZDILQXzQklmqyQj8i4FIYBmNjqrRkr+VCycFhG JHCEnZy4bN1PzclqNf8wJ5ZKjv5y2K9y+FqVeRH1DBxzZehc61kK7IOVBx21Dw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=ngraves.fr header.s=ovhmo4487190-selector1 header.b=Vsqp1VbY; 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=reject) header.from=ngraves.fr ARC-Seal: i=1; s=key1; d=yhetil.org; t=1729530859; a=rsa-sha256; cv=none; b=L+7oWG35evFttHKLxyUAK7zMqtMGuPGT4Ob1YbJB3DYd41H6B5FuUzeTQ6g3mWCCAQDWl0 Y52zGjpfgzzSvuDNV+OjFeL7LkTsem909QWnKxMkQUdGbgH9VRDd9k+bWA7+O56+rA+Xm+ vJNGyf0oXyNBjgTnLMyBOPeNRA0J+ARPj/nzosH+bB/Pv+IMoamCLhkHr271cmO3in3FpJ vcZqfxSNKHF2OBZNcVEdohDIWzUwfnlSg5LW9MzE1LP+i8Qb6jbJ+XQBKmwL9zYa1axEeB zCtUbvFuMAV3H14j3UsVUjJhAn3N2N5IahG6RU0GOPCrjku9DQ9ttXcIqXcu2w== 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 C4D1841CD1 for ; Mon, 21 Oct 2024 19:14:18 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t2vyV-0004QK-MF; Mon, 21 Oct 2024 13:13:47 -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 1t2vyS-0004PY-QF for guix-devel@gnu.org; Mon, 21 Oct 2024 13:13:45 -0400 Received: from 16.mo561.mail-out.ovh.net ([188.165.56.217]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t2vyN-00025c-Vu for guix-devel@gnu.org; Mon, 21 Oct 2024 13:13:44 -0400 Received: from director11.ghost.mail-out.ovh.net (unknown [10.108.17.93]) by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4XXMMy70WFz1RlG for ; Mon, 21 Oct 2024 17:13:34 +0000 (UTC) Received: from ghost-submission-5b5ff79f4f-tbdcs (unknown [10.110.188.95]) by director11.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 7E1A11FE06; Mon, 21 Oct 2024 17:13:34 +0000 (UTC) Received: from ngraves.fr ([37.59.142.96]) by ghost-submission-5b5ff79f4f-tbdcs with ESMTPSA id +mdZFr6LFmcxRwEAZJzkig (envelope-from ); Mon, 21 Oct 2024 17:13:34 +0000 X-OVh-ClientIp: 86.246.19.221 From: Nicolas Graves To: Superfly Johnson , guix-devel@gnu.org Subject: Re: Go Package with multiple subpackage In-Reply-To: <8f50a338-43e8-4142-90de-fb255686aaca@yahoo.com> References: <8f50a338-43e8-4142-90de-fb255686aaca.ref@yahoo.com> <8f50a338-43e8-4142-90de-fb255686aaca@yahoo.com> Date: Mon, 21 Oct 2024 19:13:33 +0200 Message-ID: <878quhv0oy.fsf@ngraves.fr> MIME-Version: 1.0 Content-Type: text/plain X-Ovh-Tracer-Id: 10069485819040883253 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeftddrvdehledguddutdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffujghffffkgggtsehttdertddttddtnecuhfhrohhmpefpihgtohhlrghsucfirhgrvhgvshcuoehnghhrrghvvghssehnghhrrghvvghsrdhfrheqnecuggftrfgrthhtvghrnhepheevgeejffeigeevgffgtefhheeuffduudevfeettdegheefhfegieeiffdvgffhnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpghhordguvghvnecukfhppeduvdejrddtrddtrddupdekiedrvdegiedrudelrddvvddupdefjedrheelrddugedvrdelieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepnhhgrhgrvhgvshesnhhgrhgrvhgvshdrfhhrpdhnsggprhgtphhtthhopedupdhrtghpthhtohepghhuihigqdguvghvvghlsehgnhhurdhorhhgpdfovfetjfhoshhtpehmohehiedupdhmohguvgepshhmthhpohhuth DKIM-Signature: a=rsa-sha256; bh=MeTkiwMI2cGmd7hucdKoOylrbhaujsxepqhrJi4nxFs=; c=relaxed/relaxed; d=ngraves.fr; h=From; s=ovhmo4487190-selector1; t=1729530815; v=1; b=Vsqp1VbYbCtglQMRPYXlRA2u8FIHqRrQLOZGr+A56w68WWfFaCCteTyUcbUBioRsPfZ1iLlZ IPT+fHOz0LUvcq85Pz4dVIpGV24Kbyzd0+ghhY+8EiaZagA8QLN7svHBtQ/TAM/Zx95tQzepvek NZTvXGLfah/rirkHUewajm7qTfEl503bGufZnNzRi8sVpwhS55oYVIBUqB9AXXkTFffPUmGxY16 sDrTa5xHbc4XXQ4O4o0x7JX0SOZR+b2jBeyQrtKD3OwQutOS1qq3wrKogEL0AcybJsNI9DZZBqw l7kflUGylf2mw7s833DgqZopW9QqR0A1gEq13TKWR+Ieg== Received-SPF: pass client-ip=188.165.56.217; envelope-from=ngraves@ngraves.fr; helo=16.mo561.mail-out.ovh.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx11.migadu.com X-Migadu-Spam-Score: -1.53 X-Spam-Score: -1.53 X-Migadu-Queue-Id: C4D1841CD1 X-TUID: sA8KA1gEuatW On 2024-09-22 13:21, Superfly Johnson wrote: > The Azure SDK for Go > (https://github.com/Azure/azure-sdk-for-go/releases) has many > sub-packages within the same directory and the guix import method won't > work directly. I think the best solution for packaging the requirements > for rclone would be to make the sub-packages individual guix packages > using the url-fetch method instead of the git method. Each also depends > on several sub-packages. > > Thoughts? There are possibilities for some build-systems to work on a workspace of packages rather than a single package. I remember I implemented that on a version of the rust-build-system (never released, would take me quite some time to begin working on that again), and the Node also considers working with packages. When the design is good, you can even consider everything as a workspace, since a package can be "a workspace of one package", and have a single build-system being able to build all packages inside a repo, much like submodules. In this case you could have a single guix package with multiple outputs for each workspace's package. In my case I had for instance a single pull of a repo with multiple crates such as https://github.com/RustCrypto/elliptic-curves and multiple outputs, each one for a single package. I don't know if a modification of the go-build-system would be able to handle that, but it seems that go also have a way to handle workspaces : https://go.dev/blog/get-familiar-with-workspaces I think it's a great direction to ease package update on Guix, since all the complexity is handled in the build-system and upstream rather than at the level of guix maintenance / user. And if a rust or node workspace behaves poorly for some reason, then for this one we can still go back to packages for this workspace. Although it's a big more tricky when regarding things like searching packages, because it introduces a new kind of "output-package". Maybe using something like (define-public my-package (package (name ...) (source `(,workspace "output-name")) (build-system copy-build-system) (description ...) ...)) could be a solution to handle this. Now to also answer on the issue raised by Denis, I agree that it's better not to debundle when there are a lot of dependencies and when the dependencies are not already packaged in Guix. Rationale is that there is no space gain in debundling something that is not present elsewhere, and indeed leaving certain things bundled might make it easier to build. Also we can debundle partly based on what makes the more sense regarding both space gains and maintainability : replace a few big library dependencies but leave a few small ones not present elsewhere in Guix in the source (ungoogled-chromium does that for instance). -- Best regards, Nicolas Graves