From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id MO+8APTHL2HhKgEAgWs5BA (envelope-from ) for ; Wed, 01 Sep 2021 20:35:32 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id yMvPN/PHL2GNPgAA1q6Kng (envelope-from ) for ; Wed, 01 Sep 2021 18:35:31 +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 75FEC17BF4 for ; Wed, 1 Sep 2021 20:35:31 +0200 (CEST) Received: from localhost ([::1]:55368 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLV58-0001Fd-En for larch@yhetil.org; Wed, 01 Sep 2021 14:35:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35340) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLV4e-0001FA-AE for guix-devel@gnu.org; Wed, 01 Sep 2021 14:35:00 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:61445) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLV4Y-0007CX-Qp for guix-devel@gnu.org; Wed, 01 Sep 2021 14:34:59 -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 4H0CQY2V6Gz3x6f; Wed, 1 Sep 2021 20:34:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1630521285; bh=s8KBVOsHZPYVl84xMZcDAhRNlafIC85yDtdhD71NFIQ=; h=Subject:From:To:Date:In-Reply-To:References; b=LVtiu/Pq5zhDD2D/Rk5gvUoKAX+IzH/YehC3ghxcfkzdslMirigNl3Sdke0ZiRJM/ HGd680bhk+WmG/ofGKdlpiKkA/PHrBJxycCNGnjFORdjdLHKB/Z5v8PK4UdLXr6bJH ozCp93abi3PFiXaAlGk34QS99Kw9n1CGvDDd4c4U= Message-ID: <27af2d4efec4ced1e8411b1d993dbc8112d26cb7.camel@student.tugraz.at> Subject: Re: Can we find a better idiom for unversioned packages? From: Liliana Marie Prikler To: Maxime Devos , Sarah Morgensen , guix-devel@gnu.org Date: Wed, 01 Sep 2021 20:34:44 +0200 In-Reply-To: <1e58de895f638d897ea89647344ef24c40ea3ec2.camel@telenet.be> References: <8635qp1j6k.fsf@mgsn.dev> <473ea45f79b94ff04327f3fdf691dd8e4a85f7ba.camel@telenet.be> <1e58de895f638d897ea89647344ef24c40ea3ec2.camel@telenet.be> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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: , 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=1630521331; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=s8KBVOsHZPYVl84xMZcDAhRNlafIC85yDtdhD71NFIQ=; b=gEQ+7AOCGjpdnjQQQ8hvJDq+ko+jLyQABpoBxKnOIrdVFe/lOcaQNMZeTOjklP05Uo+97m 9ohw88tUkXzcNBjO+c0Uzo/CrDrMyl3d/G9pwqSlmdBMETzfugGalJbX5Y9VtUTYQ4NEEH Vq9AFrrgQba6n+6ww72kBrBNGMitHyhxqL5F7wbmqXjIIo0lESYiaj4/ifyRY8a7SeC70q dtEwfu6yN7RW166BT6EQ0LABiivSTb12jQZfw0XMHUgDE/3MskO5rBFkt2cqaMXVU7HJhf +FsO+XNNZ10s1nVHYH1iHrh7VnBsaY4tkfhxSGyKgwkEF6O4NXmJu4sh3pcdUg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1630521331; a=rsa-sha256; cv=none; b=Y4CWIoAyQGDQlF7uZbcuqAUyAZqBdqR+MwWLzZhbkR/p9evt8WAxMJRLjd9BKpELz2x3cx QijTPLs4KBRTbBn53TmA0b9RHPxaHa7zFVaQGAMsQ+qQY8lk7aI8hkAh9rvEGLgrz4y/c9 Cdc4cCZOF4f0C6mCLBrRjsz11f5emqmSSlIpOQ80ONUL70aC10K0omx2M6/QMtyeZu+acJ bZgIlvUSj6sRt+/DPFzB2ltQU+aoBhLMKnaie4LiN5A3/09PMG9xGsR7EwdE8FXSNysU3x 64X/LVd5MJgIiTO4hf0mwCE3HXoNCugBwTFX8D7tKBdmy/yhV7HNSW/nxGtAaQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b="LVtiu/Pq"; dmarc=pass (policy=none) header.from=student.tugraz.at; 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: -2.12 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b="LVtiu/Pq"; dmarc=pass (policy=none) header.from=student.tugraz.at; 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: 75FEC17BF4 X-Spam-Score: -2.12 X-Migadu-Scanner: scn1.migadu.com X-TUID: vvOWvOOOsZj4 Am Mittwoch, den 01.09.2021, 18:39 +0200 schrieb Maxime Devos: > Liliana Marie Prikler schreef op wo 01-09-2021 om 15:33 [+0200]: > > 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. > > > > > > 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? > > Not losing the revision is useful for things like > , to be able to determine the old > revision. (That's not about inheriting packages though.) Isn't that addressed by addressing the second point, though? Like, if you know the source location of the revision, you can read it back to get the value itself (or possibly even access it as-is), no? > > [...] > > > 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 from 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' expect it to return a string. Maybe adding a keyword > > > argument '#:full-version? #t/#f' defaulting to #f would work? > > I think the bigger problem here is that you're moving bits meant > > for > > the origin into the version only to be able to point to the version > > from the origin. Even accepting that you could use "commit" or a > > separate field to encode SVN/CVS revision numbers instead of > > hashes, > > everything beyond the revision number is basically pointless from a > > versioning scheme POV and only really useful to fetch the source > > code. > > As Xinglu Chen points out, a commit hash encodes remarkably little > > on its own. > > The commit is largely useless, ok. If the (first few characters of) > the git commit/svn revision are removed from the version strings, it > can be removed from the proposed extended-version. > > Otherwise, it would seem you wouldn't mind extended-version if it > only had the 'base version' and 'revision' field (in the guix sense, > not the SVN sense of revision), or am I misunderstanding here? That was not my suggestion, but let's entertain the idea, shall we? In that case, we would discard the commit part from the version field, which might not be everyone's tea, but I'm more or less indifferent as to whether to include the hash there or not – after all, even if it was lacking, we'd quickly get it through inspecting the package description. If we simply didn't capture the hash at all except inside the commit field of the origin, we would gain 1, 4 and 5 so the question is whether we should have an extended version so as to update the revision more easily... My personal answer to this might be a disappointing one, as in that case I believe we wouldn't even need procedures like git-version to form them, but could instead use - as a mere convention like many more popular distros already do. If the dash is overused for that, we could also use a different symbol, though perhaps there's not that many on a typical US keyboard to reserve one as a revision delimiter. Making our rando commit git versions look like such other distro versions does come at a disadvantage though, particularly when we look at it through the lense of someone not used to Guix' versioning scheme. Instead of telling us "yeah, this is the Nth time we picked a rando commit since the last release and this time it's de4db3ef", users coming from such distros would assume "oh well, this is still good ol' 1.0 with some more patches applied". So while the commit itself does not give us any particularly useful information (unless you're that person who uses this part of the version string to look the commit up on hubbucket), especially not when thinking in the context of versioning scheme, it does provide the existential information of "hold on, this is not a release commit, it's something else" and might thus direct users to be a little more attentive when they'd otherwise go "yep, upstream considers this solid and Guix considers it even more solid, so it's the solidest". Note, that this can be overcome both by teaching/learning about it and by using a special sigil as mentioned above. All in all, I don't think putting too much "opinion" in the version field by storing it as a record is a good idea. It's fine if it's just a string that can be parsed/version-compared. We could also make it a list like Emacs does and like we use internally, though I'm not too certain of what the benefit of that would be at the cost of breaking pretty much everything (and probably putting in some opinions as to what is to be delimited by dots and what by dashes). Regards