From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id AK1DMjSdLmEvZQAAgWs5BA (envelope-from ) for ; Tue, 31 Aug 2021 23:20:52 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id QJv7LTSdLmEnVwAA1q6Kng (envelope-from ) for ; Tue, 31 Aug 2021 21:20:52 +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 92F932A71 for ; Tue, 31 Aug 2021 23:20:52 +0200 (CEST) Received: from localhost ([::1]:35944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLBBb-00039u-GS for larch@yhetil.org; Tue, 31 Aug 2021 17:20:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38130) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLBBF-00039W-Le for guix-devel@gnu.org; Tue, 31 Aug 2021 17:20:30 -0400 Received: from baptiste.telenet-ops.be ([2a02:1800:120:4::f00:13]:52982) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mLBBD-0000FR-Et for guix-devel@gnu.org; Tue, 31 Aug 2021 17:20:29 -0400 Received: from ptr-bvsjgyjmffd7q9timvx.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:aaf1:9810:a0b8:a55d]) by baptiste.telenet-ops.be with bizsmtp id oMLN250050mfAB401MLNks; Tue, 31 Aug 2021 23:20:22 +0200 Message-ID: <473ea45f79b94ff04327f3fdf691dd8e4a85f7ba.camel@telenet.be> Subject: Re: Can we find a better idiom for unversioned packages? From: Maxime Devos To: Sarah Morgensen , guix-devel@gnu.org Date: Tue, 31 Aug 2021 23:20:10 +0200 In-Reply-To: <8635qp1j6k.fsf@mgsn.dev> References: <8635qp1j6k.fsf@mgsn.dev> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-hCKBGGxYU+WGfxWoNjkD" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1630444822; bh=DNXpzGuCtW5MHKLXtlsjbCfAK2AKQDxpXFLdb+QfMCE=; h=Subject:From:To:Date:In-Reply-To:References; b=DIaGpeC9MiTHWRAZlPJuU9XrSWUzDpX1TG0xTKZa2lS6TQZiwZUO8tu5ciLdrju4+ EsGJ4r1oaeibXUZkL01UYTxRYw/4vDw2paYuE9yp9se5V3GaVD+IBXMmIEXwwSYpqZ XFTv+nxptl1/gecI53BYaDc5pz9XIm5ixkVqw8PKjzrrYmhGYn6ie3JJU56+bEu95d mQW2MMzjBWbSogF6Pk6JcajW911wpAYim0CDALqwapqwPzb1tp+dRX75osBMfalec3 x+EYJujKmluToBGrjREOU020nnlaCD7X4AOlpuR4SbQe1fpXSLU80zPh7iedtz8cEH qsV+V92WHOmPw== Received-SPF: pass client-ip=2a02:1800:120:4::f00:13; envelope-from=maximedevos@telenet.be; helo=baptiste.telenet-ops.be 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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.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: 92F932A71 X-Spam-Score: -4.00 X-Migadu-Scanner: scn0.migadu.com X-TUID: /dPIqDyrVM1r --=-hCKBGGxYU+WGfxWoNjkD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sarah Morgensen schreef op di 31-08-2021 om 12:57 [-0700]: > Hello Guix, >=20 > Currently, there are about 1500 packages defined like this: >=20 > --8<---------------cut here---------------start------------->8--- > (define-public sbcl-feeder > (let ((commit "b05f517d7729564575cc809e086c262646a94d34") > (revision "1")) > (package > [...]))) > --8<---------------cut here---------------end--------------->8--- >=20 > I feel like there are some issues with this idiom (in no particular > order): >=20 > 1. When converting between this idiom and regularly versioned packages, > the git diff shows the whole package changing because of the indentation > change. >=20 > 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. >=20 > 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. >=20 > 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...) >=20 > 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. Suggestion: extend the 'version' field. More specifically, introduce a new record , like this: (define-record-type* extended-version make-extended-vers= ion extended-version? this-version ;; something like 1.2.3 (TODO better name) (base extended-version-base) (revision extended-version-revision) (commit extended-version-commit)) (define (version->string version) (match version ((? string?) version) (($ ...) code from original git-version and hg-vers= ion))) ;; TODO: ;; adjust git-file-name and hg-file-name to accept recor= ds ;; (as well as the =E2=80=98old style=E2=80=99 for compatibility) To be used like: (define-public sbcl-feeder (name "sbcl-feeder") (version (extended-version (base "1.0.0") (revision 1) (commit "b05f517d7729564575cc809e086c262646a94d34"))) (source (origin (method git-fetch) (uri (git-reference ...) (url ...) ;; git-reference needs to be extended to retrieve the commit fro= m the version (version version))) (file-name (git-file-name "feeder" version)) (sha256 ...))) [...]) That should address 1,2,3,4 and 5. One problem with this approach is that most users of 'package-version' expe= ct it to return a string. Maybe adding a keyword argument '#:full-version? #t= /#f' defaulting to #f would work? Greetings, Maxime. --=-hCKBGGxYU+WGfxWoNjkD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYS6dChccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7rQbAQDppkVILAQ9nGVKM6m4DUWtKMF8 1wQWcAPKNe1/LRjtIgEAloEGvux0UJVszERP6cI/1sDNR7eYAq3D1f6bIgz+EwA= =ywT3 -----END PGP SIGNATURE----- --=-hCKBGGxYU+WGfxWoNjkD--