Hi there! I've been following the "guix git" discourse with interest because I know a lot of people who care about pinning packages to specific versions and selecting specific versions of software to install. This constituency currently relies heavily on systems like rvm, nvm, and conda to manage the available versions of libraries and runtimes they 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 packages using the git log, but that doesn't address the questions "which versions of this software are available and how to I use them" except via an abstraction that depends on the operator's tacit knowledge, including what "git" is and how to read git commits. We can do better.
I propose a different approach: the "guix versions" subcommand provides direct answers to practical user questions.
- What package versions are available?
- How do I use them?
- Which versions are known to be vulnerable?
- Which have available substitutes?
For example, the command "guix versions esbuild" can provide this output:
name: esbuild
version: 0.8.21
guix-hash: eee3af86c7
name: esbuild
version: 0.8.19
guix-hash: 6374a25357
name: esbuild
version: 0.8.16
guix-hash: 8c3caf9c5d
vulnerabilities: cve-2020-1337, cve-2019-1024
...and so on.
Then, to make the output directly actionable, we extend Guix to accept recfile manifests following the same structure, such that given the following file "packages.rec:"
name: esbuild
version: 0.8.19
guix-hash: 6374a25357
name: python-html5lib
version: 1.1
guix-hash: 6374a25357
…we can use those exact packages using "guix environment -m packages.rec", or find which of those packages have substitutes using "guix weather -m packages.rec"
I make this proposal because I perceive the following advantages:
- It makes no the assumption that the operator knows what git is, cares about the internal git structure of Guix, wants to read git commits, 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 which depend upon the operator's tacit knowledge.
- The user can act immediately upon the output of the command to create a manifest that represents the software they want to use.