[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pinning package inputs using inferiors?
From: |
zimoun |
Subject: |
Re: Pinning package inputs using inferiors? |
Date: |
Mon, 24 Oct 2022 10:06:11 +0200 |
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