Re: Finding versions of packages

[Ludovic Courtès]

Hi!

Ryan Prior <ryanprior@hey.com> skribis:

> 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.

Interesting.  I think it could grab information locally (from the
available ‘guix pull’ generations) and from the Guix Data Service.

However, it might give the false idea that users can pick
package versions independently (as in: I want esbuild X, GCC Y, and Go
Z), which is not really the case: packages are interrelated.

> 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.

Yeah, I think ‘guix git log’ can be very useful for developers, but is
not a great UI for browsing package history for the reasons you give.

> - 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.

Yes, that is a really nice property, as long as it doesn’t suggest that
one can do that with any number of packages at once.  (Whether ‘-m’
should accept rec files or not can be treated separately.)

Thanks,
Ludo’.