From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 8C+HMD+TpWVRuwAAqHPOHw:P1 (envelope-from ) for ; Mon, 15 Jan 2024 21:19:11 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 8C+HMD+TpWVRuwAAqHPOHw (envelope-from ) for ; Mon, 15 Jan 2024 21:19:11 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=retrospec.tv header.s=fm2 header.b=bqM7Fl3L; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=Biu+yuGk; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1705349951; 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:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=K5/h9Oxf8aM18Da+KxwBfD4xO1RSP7Yxaqhs5D2Oovc=; b=gNO/a0afV6U4fYOEBJHEpISOl5NceiVNniR56c4O3cT8dfVeFFdqRJpVwk0RKYRyZal5AP UiI06ytiOCFqXo2AYsZpK9M2bbekW6JAW/toGgnjmhtO/GSJ0tg/yb+7rhssbNrThr5Avc Cvdk0vD1KdNBu7J+KxGYRQnopPtY0555lqNo03Bz2NQlIRoiGjMnTbQNbuc2nX0wITn3Ex APsQ9dq9OO04I8/A+77KF7JUh0R7AORNKfz09iwyi1HHremKJoyLrxwJCxX05V7qwHhZ5w 7hBFnYtaBOgALqzg+3hSPc6m33rcBSUtHxh+cmm+DDSQDgJztEjLVViEL1djYA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=retrospec.tv header.s=fm2 header.b=bqM7Fl3L; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=Biu+yuGk; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1705349951; a=rsa-sha256; cv=none; b=Q5D52jYbMk7rgiaMmvLMXiwa6GbxPOLqc8QEjLbFdm4UtJIhNU05U9aiofmERVkFM1WhAy sS0spx+GtWoo5iqnjIynnkT3h6pGBokjMU/SydNksVruYHtAxdww1BVwfxJPhyfVfelSvX 3TmyJtVb61heK0VVkaC+glDN6I7TfmA7By/6JoL/N8DsT88P88anHVTHbF8xCedKP8vopc Q78SuHt7eBHs+YHQyD7lVjLchDq04T05SvyMLlrvr1nC4ZpP/Bp4G0nCIRF6qCdXRnxoB+ 2l3ICv2AwZmjnNqben6KYqHCZ+qf5RonhVnejbbUyqDJ1DExi9xahrPN3VHrXA== 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 95D7E40A71 for ; Mon, 15 Jan 2024 21:19:11 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPTPf-0000HG-0P; Mon, 15 Jan 2024 15:18:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rPTPa-0008WH-NI for guix-devel@gnu.org; Mon, 15 Jan 2024 15:18:24 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rPTPW-00086e-Gb for guix-devel@gnu.org; Mon, 15 Jan 2024 15:18:20 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id A04653200B28 for ; Mon, 15 Jan 2024 15:18:15 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 15 Jan 2024 15:18:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to; s=fm2; t=1705349895; x=1705436295; bh=K5/h9Oxf8a M18Da+KxwBfD4xO1RSP7Yxaqhs5D2Oovc=; b=bqM7Fl3LaYA4CKyjfa3L3YDtW4 NkknGDq9I02UFxPxFH1w9QB09wNPeFtXUUOI/qM/lUd8Nv7DIpvwQzS7Ud3vJ11C pr7fhDjBFQwU4uG1tg5d/G+wqP+CuskuTW6lD7i8Y9duw7QJH1DVKA3TMzknR62s 1nJPsGTQpy2pDp/z2ir0DCNBhL2FvhsMkqwHmvbUafT3kr/QpqoBwMd1M6kA4RH7 uJXG/ZZ2aUpUY67coYu7lVe8jhWZOAdF4Ff6fTthNhIRjAXMgB1SLc/TcDmxI5pR KZ/3+/Xb3spHOV3SXQgoqD+4eHSYkmJv4AyrJXH1cTDK+Z4rnxjOaJgYlbNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1705349895; x=1705436295; bh=K5/h9Oxf8aM18Da+KxwBfD4xO1RS P7Yxaqhs5D2Oovc=; b=Biu+yuGkQRpZ2AMP8dBU26TuYbFyYrIw1bCxzl9O/eHt tjDKXTiGIFKN7Kg+PjGFAGrDrpeAe2dLXVyE1Q+vjTuG1qEWlrxdvQd1FrhzSqPI jPtHiREfuuLHZ/AXCskk63oH7ESss6WwdAVkm7sDKxAqIQ62g/Re81E6y0QLGEwX mnmouJNZLPIS6iyH9VEiwbO0uPMt9upiZGQkx5KKj8YmE1Mk6avb5oR3zTt8789/ bYDBnfpGIgl9Nc87OTauuNJ3EjgNOsjiAWdGSP/OJIH2l89kYKhe9p+d1mpb329W Q1/DYRBoQoKsToZo/pvIwGFGopzM6h8iZroNNWXmkg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejuddgudefiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfgfhvffufffkgggtgfesthhqre dttderjeenucfhrhhomhepkfgrnhcugfhurhgvuceoihgrnhesrhgvthhrohhsphgvtgdr thhvqeenucggtffrrghtthgvrhhnpeekieeggeffhfelhffgieffveejjeehvdejffeiie efieetleevudeuleejheehjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpehirghnsehrvghtrhhoshhpvggtrdhtvh X-ME-Proxy: Feedback-ID: id9014242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 15 Jan 2024 15:18:14 -0500 (EST) User-agent: mu4e 1.10.8; emacs 29.1 From: Ian Eure To: guix-devel Subject: Guix CLI, thoughts and suggestions Date: Mon, 15 Jan 2024 11:24:29 -0800 Message-ID: <87il3upczg.fsf@retrospec.tv> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=64.147.123.19; envelope-from=ian@retrospec.tv; helo=wout3-smtp.messagingengine.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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -10.37 X-Migadu-Queue-Id: 95D7E40A71 X-Spam-Score: -10.37 X-Migadu-Scanner: mx11.migadu.com X-TUID: 1qhcomvWNO1J Greetings, As I=E2=80=99ve been learning Guix, one of the things I=E2=80=99ve found so= mewhat=20 unpleasant is the lack of consistency within the guix CLI tool.=20 It feels a bit Git-like, with not much consistency, commands that=20 non-obvioulsy perform more than operation, related commands in=20 different places in the tree, etc. Just so you know where I=E2=80=99m coming from: I=E2=80=99ve found that com= pliex=20 CLI tooling benefits from organization and consistency. The Linux=20 ip(8) command is a good example of this kind of organization: to=20 add an IP address, you use `ip address add'. To show address, `ip=20 address show', and to remove one `ip address del'. When options=20 are needed, they get added after the verb or branch in the verb=20 tree; the final verb may take positional arguments as well as=20 --long or -s (short)-form options. Some examples of where I think Guix could do better. This is an=20 illustrative list, not an exhaustive one. Inconsistent organization =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Most package-related commands are under `guix package', but many=20 are sibling commands. Examples are `guix size', `guix lint',=20 `guix hash', etc. Inconsistency between verbs and options =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Some verbs are bare-word positional arguments, and others are=20 flags to related verbs. IMO, this is the biggest problem, and=20 makes it very difficult to find all the things the CLI can do.=20 `guix package' is a major offender in this area, as it mixes verbs=20 and verb-specific options into the same level. For example,=20 installing a package is `guix package -i foo' rather than `guix=20 package install foo', removing is `guix package -r foo' rather=20 than `guix package remove foo', and listing installed packages is=20 `guix package -I' rather than `guix package installed' (or=20 similar). This means that users can express commands which *seem* like they=20 should work, but do not. For example `guix package -i emacs -r=20 emacs-pgtk -I' represents a command to 1) install emacs 2) remove=20 emacs-pgtk 3) list installed packages (which would verify the=20 previous two operations occurred). This is a valid command within=20 the accepted organization of `guix package', and doesn=E2=80=99t cause an=20 error, but doesn=E2=80=99t work: the install and remove steps are ignored.= =20 A thing I=E2=80=99ve found throughout my career is that designing systems=20 so it=E2=80=99s *impossible* to represent unsupported, nonsensical, or=20 undefined things is an extremely valuable technique to avoid=20 errors and pitfalls. I think Guix could get a lot of mileage out=20 of adopting something similar. This causes a related problem of making it impossible to know what=20 options are valid for what verbs. Will `guix package --cores=3D8 -r=20 emacs' remove the package while using eight cores of my system?=20 Will `guix system -s i686 switch-generation 5' switch me to a=20 32-bit version of generation 5? If verbs are organized better,=20 and have their own options, this ambiguity vanishes. More inconsistency =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Other parts of guix have the opposite problem: `guix system=20 docker-image' probably ought to be an option to `guix system=20 image' rather than a separate verb. Inconsistency between similar commands =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There are generations of both the system (for GuixSD) and the user=20 profile, however, they work differently. For the system, there=E2=80=99s=20 `guix system list-generations' and `guix system=20 switch-generation', but for the user profile, you need `guix=20 package --list-generations' and `guix package=20 --switch-generation=3DPATTERN'. Additionally, no help is available=20 for either of the system commands: `guix system switch-generations=20 --help' gives the same output as `guix system --help' -- no=20 description of the supported ways of expressing a generation are=20 available. Flattened verbs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Related, the generation-related commands under `guix system' ought=20 to be one level deeper: `guix system generation list', `guix=20 system generation switch' etc. Repeated options =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Many commands (`guix package', `guix system', `guix build', `guix=20 shell') take -L options, to add Guile source to their load-path.=20 This probably ought to be an option to guix itself, so you can do=20 `guix -L~/src/my-channel build ...'. Suggestions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All commands should be organized into a tree of verbs. Verbs should have common aliases (`rm' for `remove', etc). Verbs should be selected by specifying the minimum unambiguous=20 substring. For example `guix sys gen sw' could refer to `guix=20 system generation switch'. Options should be applicable to each level of the tree, ex `guix=20 -L~/src/my-channel' would add that load-path, which would be=20 visible to any command.=20=20 Requesting help is a verb. Appending "help" to any level of the=20 verb tree should show both options applicable to that verb, and=20 its child verbs. `guix help' would show global options and all=20 top-level verbs (package, system, generation, etc); `guix package=20 help' would show package-specific options and package-specific=20 verbs; and so on. Conclusion =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I have no idea if anyone feels similarly about this, or whether=20 there=E2=80=99s appetite to change the CLI, but I think it=E2=80=99d be tim= e=20 well-spent. Having some kind of agreed-upon standard for how the=20 CLI stuff is organized seems like a good thing to me, even if it=20 just stops or slows the addition of more commands with unique=20 expressions. It seems like a lot of work to change, and backwards compatibility=20 also is an issue. One option I could see working is shoving the=20 entire existing structure under a command in the new tool, so you=20 could do `guix old package -I' or similar. An alternate approach=20 would be using an environment variable to change behaviors. What do you all think? Thanks, =E2=80=94 Ian