Re: Pinning package inputs using inferiors?

[zimoun]

Hi,

On sam., 22 oct. 2022 at 22:58, Felix Lechner via "Development of GNU Guix and 
the GNU System distribution." <guix-devel@gnu.org> wrote:

> While I am relatively new to functional package management, I find it
> inconsistent that inputs in Guix are provided by variables.

What do you mean by « variables »?


> I believe the inputs should be provided by functions that deliver the
> most suitable version of a package. For most packages, that is the
> most recent version unless pinned.

What do you mean by « inputs »?

Currently, the “new” style refers to symbol as inputs which points to
other package definitions.  A package definition somehow defines a
function to build a package.  At this level, it is hard to have a
precise meaning of « suitable version of a package», IMHO.

At the CLI level, packages are referred by their name field and the most
recent version is used by default; unless a specific version as
’@1.2.3’ is appended to the name.


> A package definition would be the list of available versions rather
> than just one version.

What do you build?  Do you build the matrix of all the combinations?

The hard task of a package manager is to provide a set of packages at
their appropriated versions that works well all together.  Aside some
specific cases where the compatibility across version is guarantee, I
miss how a mutli-version definition could work in practise.

Package transformation is somehow a way to implement package definition
for several versions.  It allows to rewrite the function definition
(package) but in the same time to keep under control the combinations.


Cheers,
simon