From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id CPmwILidMmF3cAAAgWs5BA (envelope-from ) for ; Sat, 04 Sep 2021 00:12:08 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id yEL8G7idMmEaAwAAB5/wlQ (envelope-from ) for ; Fri, 03 Sep 2021 22:12:08 +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 5181DB0CA for ; Sat, 4 Sep 2021 00:12:08 +0200 (CEST) Received: from localhost ([::1]:47278 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMHPr-0003Xr-Bp for larch@yhetil.org; Fri, 03 Sep 2021 18:12:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38978) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMHPf-0003Xh-HU for guix-devel@gnu.org; Fri, 03 Sep 2021 18:11:55 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:55963) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMHPb-0001rq-IF for guix-devel@gnu.org; Fri, 03 Sep 2021 18:11:54 -0400 Received: from nijino.local (194-118-34-199.adsl.highway.telekom.at [194.118.34.199]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4H1X7y645Tz1LXsQ; Sat, 4 Sep 2021 00:11:42 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4H1X7y645Tz1LXsQ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1630707103; bh=X8jYNsMT0gHA/8d2z5OhWPE4BxLERYjvQpE3Ib8/rhU=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=B08u2UUfxgbvQn2Io4d3KXpK/6qlop5p66Br3h0aBUoxr4BVKNQZvwor9Hpsh4M2o yuxaD/hnsY7YRzGodpMfJnX9j4EaC2mLfdxgDaqXjpnBrsA15Aj9mmaODo38fNySU4 1jmhgLXMr4tghzINQaaSA426ftwsnh6421hJ8pdo= Message-ID: Subject: Re: Can we find a better idiom for unversioned packages? From: Liliana Marie Prikler To: Sarah Morgensen Date: Sat, 04 Sep 2021 00:11:41 +0200 In-Reply-To: <86o899xsyr.fsf@mgsn.dev> References: <86o899xsyr.fsf@mgsn.dev> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 Received-SPF: pass client-ip=129.27.2.202; envelope-from=leo.prikler@student.tugraz.at; helo=mailrelay.tugraz.at X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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.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 X-Migadu-Spam-Score: -4.00 Authentication-Results: aspmx1.migadu.com; none X-Migadu-Queue-Id: 5181DB0CA X-Spam-Score: -4.00 X-Migadu-Scanner: scn1.migadu.com X-TUID: 2XU+Pv56gSvL Hi Sarah, Am Freitag, den 03.09.2021, 14:14 -0700 schrieb Sarah Morgensen: > [...] > > > 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. Well, let #f or *unspecified* would also solve the git blame issue, but again I don't think the recursive git blame implemented e.g. by magit is broken too easily by those transitions. I might be wrong about that, though. > [...] > 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. The point is not so much to say "no" because all those points are minor, but rather to establish which properties a "solution" would require and which ones are simply nice to have. For example, we need to be able to update the expression in-place, but referencing its value for the sake of inheritance is not that important. > [...] > > 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. Point taken. > 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. I don't agree with your assessment. tag-prefix is not a raw string, it can be a regexp, so if upstream jumps from "v1.2.3" to "release-1.2.4", you can encode that in one regexp. You can't do that with version records. > (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'. You know, that you could alternate between version-first for tagged commits and reference-first for untagged ones, assuming you don't do the reasonable thing of wrapping the origin in a let&. Then you'd have (origin (method git-fetch) (version "2.13.3") (uri (git-reference (url "https://github.com/git-lfs/git-lfs") (commit (string-append "v" version)) [...]) and (origin (method git-fetch) (uri (git-reference (url "https://github.com/git-lfs/git-lfs") (commit "e41b504dca90a25e9be27f296da7ce22e5782893") (version (git-version "0.12.9" (git-reference-commit uri))) [...]) Of course, you could do something similar with packages as is, but (git-reference-commit (origin-uri origin)) might be a bit much. Regards