From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id AFurHH8/1V+FaQAA0tVLHw (envelope-from ) for ; Sat, 12 Dec 2020 22:09:03 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id uFJzGH8/1V+DHQAAB5/wlQ (envelope-from ) for ; Sat, 12 Dec 2020 22:09:03 +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 0F38594011C for ; Sat, 12 Dec 2020 22:09:02 +0000 (UTC) Received: from localhost ([::1]:33402 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koD4X-00019N-Mh for larch@yhetil.org; Sat, 12 Dec 2020 17:09:01 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45772) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koD4M-000192-KN for guix-devel@gnu.org; Sat, 12 Dec 2020 17:08:50 -0500 Received: from 01b.relay.hey.com ([204.62.114.225]:45809) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koD4K-0004wg-Ke for guix-devel@gnu.org; Sat, 12 Dec 2020 17:08:50 -0500 Received: from hey.com (bigip-vip-new.rw-ash-int.37signals.com [10.20.0.24]) by 01.relay.hey.com (Postfix) with ESMTP id 0AC4F100CE5 for ; Sat, 12 Dec 2020 22:08:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hey.com; s=heymail; t=1607810927; h=from:from: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; bh=0g5sGvoFU/AHo+T3gCSQgyklVLeA3gEw8UR9Orka4h4=; b=jqqlOTrS3VQ816cD6MoYR4VqNzlbL1iYXDcC6+q60PGidEOFNRuMFMk3JM42QvZheUSioW ZC5J3PMYsS+EdZ0SVDEXmM6FEvlj+Y67zJCLuDdxP9Bku3BU8sOiLAjfa+Nwih6UVRs/Ki vvskieAaUfbVZCo6vUY7o9PR5OD+VwaEgWs7kJAfP3BCv87+xlc+jYmHMKZkkEUdo1644K IJKjv6OW93gEQcdCKGYQX+/PSNNKfkOy8gnvlto6BduOtGeMSCxh3IexXSLnGVfBD0FXkx ukr0ID5la07uqin+ez1E54irjZLvZbdNjk72QVSJVe47ECaWbjHoCagPBsFm/w== Date: Sat, 12 Dec 2020 22:08:46 +0000 From: Ryan Prior To: Development of GNU Guix and the GNU System distribution Message-ID: <5ebe44900cb13f637d87309f4567624d16d3ca15@hey.com> Subject: Finding versions of packages (was: [outreachy] Walk through the Git history) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5fd53f6ebf0d1_7fdc2df01918d"; charset=UTF-8 Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=204.62.114.225; envelope-from=ryanprior@hey.com; helo=01b.relay.hey.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 X-Migadu-Spam-Score: -2.50 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=hey.com header.s=heymail header.b=jqqlOTrS; dmarc=pass (policy=quarantine) header.from=hey.com; 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: 0F38594011C X-Spam-Score: -2.50 X-Migadu-Scanner: scn1.migadu.com X-TUID: R+t7LNp11ciF ----==_mimepart_5fd53f6ebf0d1_7fdc2df01918d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi there! I've been following the "guix git" discourse with interest=0D because I know a lot of people who care about pinning packages to=0D specific versions and selecting specific versions of software to=0D install. This constituency currently relies heavily on systems like rvm,=0D= nvm, and conda to manage the available versions of libraries and=0D runtimes they care about.=0D =0D The proposal to add a "guix git" command to help find old versions of=0D packages seems unnecessarily indirect to me. Certainly you can learn=0D interesting things about the history of Guix packages using the git=0D log,=C2=A0 but that doesn't address the questions "which versions of this= =0D software are available and how to I use them" except via an abstraction=0D= that depends on the operator's tacit knowledge, including what "git" is=0D= and how to read git commits. We can do better.=0D =0D I propose a different approach: the "guix versions" subcommand provides=0D= direct answers to practical user questions.=0D - What package versions are available?=0D - How do I use them?=0D - Which versions are known to be vulnerable?=0D - Which have available substitutes?=0D =0D For example, the command "guix versions esbuild" can provide this=0D output:=0D name: esbuild version: 0.8.21 guix-hash: eee3af86c7 name: esbuild=0D version: 0.8.19 guix-hash: 6374a25357 name: esbuild version: 0.8.16=0D guix-hash: 8c3caf9c5d vulnerabilities: cve-2020-1337, cve-2019-1024=0D ...and so on.=0D =0D Then, to make the output directly actionable, we extend Guix to accept=0D= recfile manifests following the same structure, such that given the=0D following file "packages.rec:"=0D name: esbuild version: 0.8.19 guix-hash: 6374a25357 name: python-=0D html5lib version: 1.1 guix-hash: 6374a25357=0D =E2=80=A6we can use those exact packages using "guix environment -m=0D packages.rec", or find which of those packages have substitutes using=0D "guix weather -m packages.rec"=0D =0D I make this proposal because I perceive the following advantages:=0D - It makes no the assumption that the operator knows what git is, cares=0D= about the internal git structure of Guix, wants to read git commits, or=0D= wants to master the details of the internal "inferiors" mechanism we use=0D= to provide this functionality.=0D - It answers directly the operator's practical questions rather than=0D providing oblique advice which depend upon the operator's tacit=0D knowledge.=0D - The user can act immediately upon the output of the command to create=0D= a manifest that represents the software they want to use.=0D ----==_mimepart_5fd53f6ebf0d1_7fdc2df01918d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D
=0D
=0D
Hi there! I've been following the "guix git" discourse w= ith interest because I know a lot of people who care about pinning packag= es to specific versions and selecting specific versions of software to in= stall. This constituency currently relies heavily on systems like rvm, nv= m, and conda to manage the available versions of libraries and runtimes t= hey care about.

The proposal to add a "guix git" command= to help find old versions of packages seems unnecessarily indirect to me= . Certainly you can learn interesting things about the history of Guix pa= ckages using the git log,=C2=A0 but that doesn't address the questions &q= uot;which versions of this software are available and how to I use them&q= uot; except via an abstraction that depends on the operator's tacit knowl= edge, including what "git" is and how to read git commits. We c= an do better.

I propose a different approach: the "guix versi= ons" subcommand provides direct answers to practical user questions.=
- What package versions are available?
- How do I use them?
- W= hich versions are known to be vulnerable?
- Which have available subst= itutes?

For example, the command "guix versions esbuild"= can provide this output:
name: esbuild=0D
version: 0.8.21=0D
guix-hash: eee3af86c7=0D
=0D
name: esbuild=0D
version: 0.8.19=0D
guix-hash: 6374a25357=0D
=0D
name: esbuild=0D
version: 0.8.16=0D
guix-hash: 8c3caf9c5d=0D
vulnerabilities: cve-2020-1337, cve-2019-1024
...and so on.
=
Then, to make the output directly actionable, we extend Guix to accep= t recfile manifests following the same structure, such that given the fol= lowing file "packages.rec:"
name: esbuild=0D
version: 0.8.19=0D
guix-hash: 6374a25357=0D
=0D
name: python-html5lib=0D
version: 1.1=0D
guix-hash: 6374a25357

=E2=80=A6we can use those exact packa= ges using "guix environment -m packages.rec", or find which of = those packages have substitutes using "guix weather -m packages.rec&= quot;

I make this proposal because I perceive the following advant= ages:
- It makes no the assumption that the operator knows what git is= , cares about the internal git structure of Guix, wants to read git commi= ts, or wants to master the details of the internal "inferiors" = mechanism we use to provide this functionality.
- It answers directly = the operator's practical questions rather than providing oblique advice w= hich depend upon the operator's tacit knowledge.
- The user can act im= mediately upon the output of the command to create a manifest that repres= ents the software they want to use.
=0D
=0D =0D =0D
=0D =0D =0D ----==_mimepart_5fd53f6ebf0d1_7fdc2df01918d--