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 ms0.migadu.com with LMTPS id yGv/CMhcL2FbTgAAgWs5BA (envelope-from ) for ; Wed, 01 Sep 2021 12:58:16 +0200 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 kAfIBMhcL2FzeQAAB5/wlQ (envelope-from ) for ; Wed, 01 Sep 2021 10:58:16 +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 E0FEED65F for ; Wed, 1 Sep 2021 12:58:15 +0200 (CEST) Received: from localhost ([::1]:44116 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLNwc-0002fb-Hf for larch@yhetil.org; Wed, 01 Sep 2021 06:58:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46580) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLNuw-0008IR-7S for guix-devel@gnu.org; Wed, 01 Sep 2021 06:56:30 -0400 Received: from h87-96-130-155.cust.a3fiber.se ([87.96.130.155]:49492 helo=mail.yoctocell.xyz) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLNuq-00043G-Rp for guix-devel@gnu.org; Wed, 01 Sep 2021 06:56:29 -0400 From: Xinglu Chen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yoctocell.xyz; s=mail; t=1630493774; bh=STgvyXzFEd+olwyGtydpWonYQ5lhbrFmh0Y8tOR0+rM=; h=From:To:Subject:In-Reply-To:References:Date; b=s/nOdvsbjUwX8e4D6dU8x83OmO10AyuzeEJmeUBkrDz0bIVwxOHCDIla1RxW6Ljs7 sZUuop8hqpSO6BxqAiQwou35wAOK4tS+NAQyt7RkOCBOJykLrj5TYrv1ClDmUhV7Mp wEs8Dg46eIOnhp0+ggziEWGpJN00v0Ki0Y7tK4yE= To: Sarah Morgensen , guix-devel@gnu.org Subject: Re: Can we find a better idiom for unversioned packages? In-Reply-To: <8635qp1j6k.fsf@mgsn.dev> References: <8635qp1j6k.fsf@mgsn.dev> Date: Wed, 01 Sep 2021 12:55:54 +0200 Message-ID: <87bl5clg3p.fsf@yoctocell.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Received-SPF: pass client-ip=87.96.130.155; envelope-from=public@yoctocell.xyz; helo=mail.yoctocell.xyz X-Spam_score_int: 18 X-Spam_score: 1.8 X-Spam_bar: + X-Spam_report: (1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FROM_SUSPICIOUS_NTLD=0.499, PDS_OTHER_BAD_TLD=1.999, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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 X-Migadu-Spam-Score: -4.00 Authentication-Results: aspmx1.migadu.com; none X-Migadu-Queue-Id: E0FEED65F X-Spam-Score: -4.00 X-Migadu-Scanner: scn0.migadu.com X-TUID: JkwauyAiFChQ --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 31 2021, Sarah Morgensen wrote: > Hello Guix, > > Currently, there are about 1500 packages defined like this: > > --8<---------------cut here---------------start------------->8--- > (define-public sbcl-feeder > (let ((commit "b05f517d7729564575cc809e086c262646a94d34") > (revision "1")) > (package > [...]))) > --8<---------------cut here---------------end--------------->8--- > > I feel like there are some issues with this idiom (in no particular > order): > > 1. When converting between this idiom and regularly versioned packages, > the git diff shows the whole package changing because of the indentation > change. > > 2. We cannot get at the source location for the definition of 'commit' or > 'revision'. This would be useful for updating these packages with `guix > refresh -u`. There is a proposed patch [0] to work around this, but it > *is* a workaround. > > 3. Packages inheriting from it lose the definitions. For actual fields, > we have e.g. `(package-version this-package)`, but we have no equivalent > for these. > > 4. Horizontal space is at a premium, and an extra two spaces here and > there add up. (Personally, I think we could do with a > define-public-package macro to save another two spaces, but that's for > another day...) > > 5. The closest thing we have to a standardized way of generating > versions for these packages is `(version (git-version "0.0.0" revision > commit))`. We can do better than that boilerplate. > > 6. Not a direct complaint, but I feel like the overall package interface > was designed before straight-from-vcs unversioned packages were so > common, and so this idiom developed organically to work around that. > > I do not have a specific solution in mind, but I think there must be > one. I do have a few half-baked ideas, but I'm curious what we can all > come up with together. Or maybe you'll just tell me I'm just being > awfully picky :) > > [0] https://issues.guix.gnu.org/50286 I never felt like including the commit id in the version of a package was useful; e.g., just seeing the first seven characters of the commit id doesn=E2=80=99t really tell me anything about the version. I think it is more useful to put the date of the commit in the version; Nixpkgs does something like this[1]. I have started to put the date of the commit in a comment, just to make it easier for people to know how old it commit is; otherwise, one would have to find the VCS repo and find the commit just to see how old the commit is. =2D-8<---------------cut here---------------start------------->8--- (define-public foo ;; No tags; commit from YYYY-MM-DD. (let ((commit "COMMIT-ID") (revision "1")) (package ...))) =2D-8<---------------cut here---------------end--------------->8--- Instead of having showing something like foo-1.0.0-1.cabba9e users would see foo-1.0.0-1.2021-01-31 Just my 2=E2=82=AC :-) [1]: --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmEvXDoVHHB1YmxpY0B5 b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5E7sQAIpQK8172Mc05DnAvXo4iGLym+C7 eGbCqWxDGc0IJ7dyGIYehwTUZaE48vv6LBmGHnlR+EeD0qm4kCabAtKtU+Y2iSBW sQJ0OnVMomg+OeGaa1Jz4C6Gj7garT+UvtcJ6pKt7ic47FP8p7BJLcTucjSWyoV+ ozKSw/6kC7eTUi7nW7exaTvq7U5G+CuE+hPg9GgN44buXi8rnel5mQYII3EdG6Vh r6LbOPTkOO2WWwSTjGDiGtb4FTv350686EPy31muZLtxuGZM6men0+ZqixVy6uap 1eY1KThL5mE06N7Fe0r09Mt0P8OnTgGymwNR/icVe/fAAjqIsVAQxH8Ril8VlKn+ Z+cJYfAFY8K+nXIEcJVWfpRBsSXp+Q8ACjCTcUYg7R0Sy+WlrlZTwNC3K/HcZ2Uv xNFUQLmo/TQW3gG1239XV2GTIR9O5cZbNI6urs+3jtFs+ejob9BLkSQ1DWxSg2+Q MeZoJbGKgqNrGJsswRnd9oLQthyWEAh/UIwTxURr/SK10fg6SxQNUldfEcRkuXc8 clphovjlsZ9069NLULG3V45EtxNwWM3Z3oEuROYIe+zV6BcEhcBCl1Yi7QmOybs9 dtdyr90s6ORJdv8Sx8K977lkxuqrr20XsV7aqF3FTg9TmK14Fl4ZHfM/PZPQ6Z8m IvSHVsT6TNSRR+jL =xGpJ -----END PGP SIGNATURE----- --=-=-=--