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 0MiUHYeQMmGcXQAAgWs5BA (envelope-from ) for ; Fri, 03 Sep 2021 23:15:51 +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 sFn2GIeQMmFIEAAA1q6Kng (envelope-from ) for ; Fri, 03 Sep 2021 21:15:51 +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 90BCC93AA for ; Fri, 3 Sep 2021 23:15:50 +0200 (CEST) Received: from localhost ([::1]:36226 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMGXN-0006Hc-JE for larch@yhetil.org; Fri, 03 Sep 2021 17:15:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59746) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMGVy-0004dM-VY for guix-devel@gnu.org; Fri, 03 Sep 2021 17:14:23 -0400 Received: from out0.migadu.com ([2001:41d0:2:267::]:62132) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMGVv-00038x-8x for guix-devel@gnu.org; Fri, 03 Sep 2021 17:14:22 -0400 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mgsn.dev; s=key1; t=1630703653; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=5WZ5/SWnwpRM9NGXY42FweHTJx1l+0smxav5UuwyFAE=; b=BGWurvn5qFHS0o9T4NlDq68/jepYoXDQROTvyx+hFCPT5WWxFrCIMJ0SSm6RyhTZqu1zv/ bWLhlAaoS96hc8XmgEd/4ewt4y7dPmIL4DYz4ISUz6n/IHghi08WDJYoNurGd4ocR7qk8p UpNQ6U3DXP5yZcHjU2g9+SsO2kJVWLA= From: Sarah Morgensen To: Liliana Marie Prikler Subject: Re: Can we find a better idiom for unversioned packages? Date: Fri, 03 Sep 2021 14:14:04 -0700 In-Reply-To: Liliana Marie Prikler's message of "Wed, 01 Sep 2021 15:33:08 +0200" Message-ID: <86o899xsyr.fsf@mgsn.dev> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Auth-User: iskarian@mgsn.dev Received-SPF: pass client-ip=2001:41d0:2:267::; envelope-from=iskarian@mgsn.dev; helo=out0.migadu.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, 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: , Cc: guix-devel@gnu.org, Xinglu Chen 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=1630703751; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=5WZ5/SWnwpRM9NGXY42FweHTJx1l+0smxav5UuwyFAE=; b=XqEiO1GppUCbOwzpqfwcf8974huD8b5saDcuA5MoR6pe3uwi/9b/lnZ4xBHNn3szIshJFK 6a+iCw/nOXqPHaB/GK33ss6vBaXhOv9XHrxlNmbhbA/vxuVCpamdBCURbBaONhANT26On4 JoMmjfLa6NEBs5QhjAbUdG+T1H4Nrz3BYin4VQh15LrAzKuaIn2qCI/69yb6L6Z9kWWAQ+ /TYhdxMMstKXgCam/a7upn2XMcI11DxfsxzKHK98sgY2NtpiwM78pbhaibi++5DCVuheYX jjPMU9OGAskB2C+c1j9hABk497OACYq58hUd/7xW+EM1+XUhf+EwD7hN/NlFQQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1630703751; a=rsa-sha256; cv=none; b=lqHG28FE2Jv4tE8iFWfVz4MZLIVccakTS0AtgKF7TqhU4+yZIWxbDqXWK5HMP38BGT0jcZ a5xgVBzFshVsnW64ZoKyPzE5WKRxNTf4aDqy7bUVGvlwQ/Qbmd6Kv8UcBujYf2sXORlFSU VkSuApzcGfkB6GcqDQqzRcVco8uxUowVcfuVxf3j5flmWkMgP4Jl7oCewwAiqnb4Cb5+wX PwWluOoNgvb0seDzsgmKQmjHF4gBYLfaung041E+e9/ikpU8IoPNihf9FVdFPd/5gBOmTQ QEpSwnu9dJ4N7/wecM0wf75kJNcM5c/r5vMk4fR0qDKV7wmM3z/Z/mqRJAIwbw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=mgsn.dev header.s=key1 header.b=BGWurvn5; dmarc=fail reason="SPF not aligned (relaxed)" header.from=mgsn.dev (policy=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: -0.32 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=mgsn.dev header.s=key1 header.b=BGWurvn5; dmarc=fail reason="SPF not aligned (relaxed)" header.from=mgsn.dev (policy=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: 90BCC93AA X-Spam-Score: -0.32 X-Migadu-Scanner: scn1.migadu.com X-TUID: E0buoXExxGOi Liliana, Thanks for the criticism! Liliana Marie Prikler writes: > Hi > > Am Dienstag, den 31.08.2021, 23:20 +0200 schrieb Maxime Devos: >> Sarah Morgensen schreef op di 31-08-2021 om 12:57 [-0700]: >> > 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. > If you are worried about that in a frequently changing package, you > could set both to *unspecified* or #f instead, which would cause any > reference to them in a string manipulation context to fail. I don't > think that such transitions are too frequent, though, as the point is > rather to discourage them where not absolutely necessary and to use > upstream releases instead. To be clear, this point was regarding "git blame", not any programmatic manipulation. >> > 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. > Other versioning idioms would also be workarounds, wouldn't they? > >> > 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. > What purpose would extracting those serve however? > >> > 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...) > The worst offenders in horizontal space typically come from the > packages themselves and going from 79 to 81 in select outliers is AFAIU > acceptable. > >> > 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. > This concerns packages without a public release, many of which never > make one in the belief that commit hashes are valid versions (they are > not). You're largely correct, in that all these reasons are minor. I feel that they do add up, though... and, IMO, the current usage of 'let' just feels inelegant. > Perhaps we could make the point that origins can be versioned just like > packages can and should think about where the version field really > belongs. I think having a per-origin version field and making it so > that the package defaults to the origin version unless the package > itself has a version specified, might be a better solution > philosophically speaking. Technically, it would only solve 1, 4 and 5, > but there's a separate workaround for 2 and I don't really think 3 to > be that big of an issue. I like this idea. It makes sense, in that the source does have an inherent version, whether that's a blessed version number or some identifier picked by the packager. It keeps related values together. (As you predicted, this does break down when multiple units of software are packaged together and their versions don't necessarily match the version of the source-as-a-whole, but being able to override the version (as you suggested) should be sufficient.) A minor downside of this method is that developers may have to look at the source field to determine the package version if it's not directly specified in the package (programmatic access would still work). Similarly, anything which parses the raw sexps (such as committer.scm) would have to be modified to accommodate. Some ideas.... 1. Version-first (origin (version (vcs-version (base "2.13.3"))) ;; or: (version "2.13.3") ;; (would require special-casing, but url-fetch uris would not need to ;; be modified) (method git-fetch) (uri (git-reference (url "https://github.com/git-lfs/git-lfs") (commit (string-append "v" version)))) ;; or: (commit (version->tag version #:prefix "v")) (file-name (git-file-name name version)) (sha256 (base32 "0r7dmqhkhz91d3n7qfpny483x8f1n88yya22j2fvx75rgg33z2sg"))) Or, if we encode the information a la #50359 [0], but in 'vcs-version': (origin (version (vcs-version (base "2.13.3") (tag-prefix "v"))) (method git-fetch) (uri (git-reference (url "https://github.com/git-lfs/git-lfs") (commit (vcs-version->git-commit version)))) (file-name (git-file-name name version)) (sha256 (base32 "0r7dmqhkhz91d3n7qfpny483x8f1n88yya22j2fvx75rgg33z2sg"))) In some ways it makes more sense to put e.g. tag-prefix in vcs-version, rather than package properties, because the transformation can occasionally vary between versions. (origin (method git-fetch) (version (vcs-version (base "0.12.9") (identifier "e41b504dca90a25e9be27f296da7ce22e5782893") (revision "1"))) (uri (git-reference (url "https://github.com/nosarthur/gita") (commit (vcs-version->git-commit version)))) (file-name (git-file-name name version)) (sha256 (base32 "1k03zgcbhl91cgyh4k7ywyjp00y63q4bqbimncqh5b3lni8l8j5l"))) Another advantage to this approach is that a potential git updater only has to change the 'version' record. 2. Reference-first (define* (git-ref->version ref #:optional base (revision "0") #:key prefix suffix) (if base (vcs-version (base base) (identifier (git-reference-commit ref)) (revision revision)) (let ((prefix-len (or (and=> prefix string-length) 0)) (suffix-len (or (and=> suffix string-length) 0))) (vcs-version (base (string-drop (string-drop-right ref suffix-len) prefix-len)) (tag-prefix prefix) (tag-suffix suffix))))) (origin (method git-fetch) (uri (git-reference (url "https://github.com/git-lfs/git-lfs") (commit "v2.13.3"))) (version (git-ref->version uri #:prefix "v")) (file-name (git-file-name name version)) (sha256 (base32 "0r7dmqhkhz91d3n7qfpny483x8f1n88yya22j2fvx75rgg33z2sg"))) (origin (method git-fetch) (uri (git-reference (url "https://github.com/nosarthur/gita") (commit "e41b504dca90a25e9be27f296da7ce22e5782893"))) (version (git-ref->version uri "0.12.9" "1")) (file-name (git-file-name name version)) (sha256 (base32 "1k03zgcbhl91cgyh4k7ywyjp00y63q4bqbimncqh5b3lni8l8j5l"))) Hmmm. I think this method falls short of the previous because we're forced to work backwards from the tag, and it splits the information relevant for updating between 'version' and 'uri'. Perhaps 'vcs-version' should actually be separated into 'tagged-version' and 'improper-version' or similar? [0] Add 'generic-git' updater. -- Sarah