From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 0NqRHTqBL2HElwAAgWs5BA (envelope-from ) for ; Wed, 01 Sep 2021 15:33:46 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id nIMcGTqBL2EMBgAAbx9fmQ (envelope-from ) for ; Wed, 01 Sep 2021 13:33:46 +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 982F5D9A8 for ; Wed, 1 Sep 2021 15:33:45 +0200 (CEST) Received: from localhost ([::1]:52146 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLQN6-0006Wf-N3 for larch@yhetil.org; Wed, 01 Sep 2021 09:33:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51730) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLQMh-0006V6-IC for guix-devel@gnu.org; Wed, 01 Sep 2021 09:33:20 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:20575) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLQMd-00031h-Ad for guix-devel@gnu.org; Wed, 01 Sep 2021 09:33:18 -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 4H04kY4xYFz3wHF; Wed, 1 Sep 2021 15:33:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1630503189; bh=rWTta0zfeXHbD2eOr3LLeq4Ogp33llQa/SLmYimZDHk=; h=Subject:From:To:Date:In-Reply-To:References; b=HT70R/fEg/cn3znM+vtilTfPKVN87jSz605YQVmdmTCEv5GQMVBxHRbMoqSerEtBI X+OKUk8Uh9lNzY7SC2/MYvpQcCM4kh9nmnUI/ZCzPAxL/7NVTMzo1tsYPoOTjrVcBL eeeV43QlhjrpqVQbNXa6s+/V3zdxWG8z5hUH2boM= Message-ID: 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 15:33:08 +0200 In-Reply-To: <473ea45f79b94ff04327f3fdf691dd8e4a85f7ba.camel@telenet.be> References: <8635qp1j6k.fsf@mgsn.dev> <473ea45f79b94ff04327f3fdf691dd8e4a85f7ba.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.116 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=1630503226; 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=rWTta0zfeXHbD2eOr3LLeq4Ogp33llQa/SLmYimZDHk=; b=GWkmC8NlUyZAqIduiyvYRQtpfNxs6TJ6uYxNAMecprLHBAYgHQDR1PZZCAHhSbukbLAwwt YBvvLRo0gvv64UdrwW1LnNdw3z/29ZsKlC7cB7anN7CvSDriXIvLuEJ6yXl3bvIxv2M/ZL F/ML6CKvPEBIEg/BG9utWizSjV2kq3XZvlDVNb8P06+amiHx2932v6LIXrcXqNwppF1Ulm 8DClBauzIOj39POZP9uChBHYHaXovkvhlI13sp7asS9ShfIBf6hB6E0rhsUlQEwTlkdjeh tka0NH6Vn0GPt5cQ7eVHy/sMsExzgNVlzm4xiw/YqJooiGXvIgX2tzNaSFD81Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1630503226; a=rsa-sha256; cv=none; b=bAbR5Wid7gslRy3mypsllH+EXElky3aj7l/VTZ9CnIL/56FbOhKuKsfNuIqiQYotIhbyZ5 80fkhHsaH8i08lmUo1FyVffyVB57n011LNbC7k0dio6eyq5eXrmPj5zWk4KJswFQdMjjJw QJ73vgjvDWVOwDa0FP7ABOb9Ri3rfTZmGQNHDuLiJ8v/5S2F6afjekOmcjfQIkDp16GzOh Qmn4g53yDAsYeXUC0t+q7KKuluiuDSN0Mb6tWnNmvviDYI9RRkU/R/lzyfcqQjamvltyN7 pJxIHHXPgyKI9hxiTNNMOskEkrr9xn0qpxmWcAmKsxQWDEBNilZW6mt5Icd2LQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b="HT70R/fE"; 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="HT70R/fE"; 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: 982F5D9A8 X-Spam-Score: -2.12 X-Migadu-Scanner: scn0.migadu.com X-TUID: 2RRXWdN7qV+b 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? > > 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). > Suggestion: extend the 'version' field. More specifically, > introduce a new record , like this: > > (define-record-type* extended-version make- > extended-version > 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-version))) > > ;; TODO: > ;; adjust git-file-name and hg-file-name to accept > records > ;; (as well as the ‘old style’ 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 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. 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. Regards