properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Simon Tournier]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

Hi,

As bug#60200 [1], the issue is one that many of us often hit: packages
with several versions and when the highest one is not the default.

Other said, build systems use some version for compiler and tools but
Guix can also offer more recent versions for these very same compilers
and tools.  It leads to the issue when selecting the name of a compiler
or tool (command line or manifest).  The user does not get the ones used
as default by build system.

In addition to [1], another example:

--8<---------------cut here---------------start------------->8---
$ guix shell ocaml ocaml-ppxlib -- ocaml --version
The OCaml toplevel, version 5.0.0
--8<---------------cut here---------------end--------------->8---

But the OCaml libraries are built using OCaml compiler v4.14, thus it
leads to error as:

--8<---------------cut here---------------start------------->8---
Error: /gnu/store/vglxlc8riynj1g937clvwv8yg40lln6z-profile/lib/ocaml/site-lib/ppxlib/ppxlib.cmi
       is not a compiled interface for this version of OCaml.
It seems to be for an older version of OCaml.
--8<---------------cut here---------------end--------------->8---

For other cases, such issue is avoided by appending the suffix -next to
package name; as with ghc-next, python-numpy-next, emacs-next, etc.

Personally, I find the -next trick useful because the package name
reflects that it is not the default.  However, it can be annoying to
update manifest files when this -next is becoming default.

Well, what do people think about this Lars’s patch?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 2317 bytes --]

diff --git a/gnu/packages.scm b/gnu/packages.scm
index 61345f75a9..7e5a6d49c2 100644
--- a/gnu/packages.scm
+++ b/gnu/packages.scm
@@ -356,20 +356,24 @@ (define cache
            (find-packages-by-name/direct name version))))
 
 (define (find-best-packages-by-name name version)
-  "If version is #f, return the list of packages named NAME with the highest
-version numbers; otherwise, return the list of packages named NAME and at
-VERSION."
+  "If version is #f, return the list of packages named NAME with only
+packages marked default? or, if none exist, the highest version numbers;
+otherwise, return the list of packages named NAME and at VERSION."
   (if version
       (find-packages-by-name name version)
       (match (find-packages-by-name name)
         (()
          '())
         ((matches ...)
-         ;; Return the subset of MATCHES with the higher version number.
-         (let ((highest (package-version (first matches))))
-           (take-while (lambda (p)
-                         (string=? (package-version p) highest))
-                       matches))))))
+         ;; Return the subset of MATCHES which are marked default or those with
+         ;; the higher version number.
+         (let ((highest (package-version (first matches)))
+               (default (filter (lambda (p) (assoc-ref (package-properties p) 'default?)) matches)))
+           (if (not (null? default))
+               default
+               (take-while (lambda (p)
+                             (string=? (package-version p) highest))
+                           matches)))))))
 
 ;; Prevent Guile 3 from inlining this procedure so we can mock it in tests.
 (set! find-best-packages-by-name find-best-packages-by-name)
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index b4566b41cc..2d5e0add26 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -3855,7 +3855,10 @@ (define* (make-gcc-toolchain gcc
                 ("libc-static" ,libc "static"))))))
 
 (define-public gcc-toolchain
-  (make-gcc-toolchain gcc-final))
+  (let ((parent (make-gcc-toolchain gcc-final)))
+    (package
+      (inherit parent)
+      (properties (alist-cons 'default? #t (package-properties parent))))))
 
 (define-public gcc-toolchain-4.8
   (make-gcc-toolchain gcc-4.8))

[-- Attachment #3: Type: text/plain, Size: 87 bytes --]



1: <http://issues.guix.gnu.org/msgid/Y6BSQpbK7BgW5Idk@noor.fritz.box>

Cheers,
simon

Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Csepp]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> As bug#60200 [1], the issue is one that many of us often hit: packages
> with several versions and when the highest one is not the default.
>
> Other said, build systems use some version for compiler and tools but
> Guix can also offer more recent versions for these very same compilers
> and tools.  It leads to the issue when selecting the name of a compiler
> or tool (command line or manifest).  The user does not get the ones used
> as default by build system.
>
> In addition to [1], another example:
>
> $ guix shell ocaml ocaml-ppxlib -- ocaml --version
> The OCaml toplevel, version 5.0.0
>
>
> But the OCaml libraries are built using OCaml compiler v4.14, thus it
> leads to error as:
>
> Error: /gnu/store/vglxlc8riynj1g937clvwv8yg40lln6z-profile/lib/ocaml/site-lib/ppxlib/ppxlib.cmi
>        is not a compiled interface for this version of OCaml.
> It seems to be for an older version of OCaml.
>
> For other cases, such issue is avoided by appending the suffix -next to
> package name; as with ghc-next, python-numpy-next, emacs-next, etc.
>
> Personally, I find the -next trick useful because the package name
> reflects that it is not the default.  However, it can be annoying to
> update manifest files when this -next is becoming default.
>
> Well, what do people think about this Lars’s patch?

As I *just* ran into some OCaml and GCC related issues a few days ago,
I'm in favor of either the default flag or expanding the -next suffix
naming convention to more packages.

Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[pukkamustard]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> $ guix shell ocaml ocaml-ppxlib -- ocaml --version
> The OCaml toplevel, version 5.0.0

I also encountered this and was surprised.

> Personally, I find the -next trick useful because the package name
> reflects that it is not the default.  However, it can be annoying to
> update manifest files when this -next is becoming default.
>
> Well, what do people think about this Lars’s patch?

I like it.

I think adding the `default?` property is nicer than the -next
trick. Only nitpick: I would maybe call the property `default-version?`
to make meaning of the property more explicit.

Cheers,
pukkamustard

Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Ludovic Courtès]

Hello,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> Other said, build systems use some version for compiler and tools but
> Guix can also offer more recent versions for these very same compilers
> and tools.  It leads to the issue when selecting the name of a compiler
> or tool (command line or manifest).  The user does not get the ones used
> as default by build system.
>
> In addition to [1], another example:
>
> $ guix shell ocaml ocaml-ppxlib -- ocaml --version
> The OCaml toplevel, version 5.0.0
>
>
> But the OCaml libraries are built using OCaml compiler v4.14, thus it
> leads to error as:
>
> Error: /gnu/store/vglxlc8riynj1g937clvwv8yg40lln6z-profile/lib/ocaml/site-lib/ppxlib/ppxlib.cmi
>        is not a compiled interface for this version of OCaml.
> It seems to be for an older version of OCaml.
>
> For other cases, such issue is avoided by appending the suffix -next to
> package name; as with ghc-next, python-numpy-next, emacs-next, etc.
>
> Personally, I find the -next trick useful because the package name
> reflects that it is not the default.  However, it can be annoying to
> update manifest files when this -next is becoming default.

To me it’s mostly a packaging issue: I would expect ‘ocaml’ to be able
to use ‘ocaml-ppxlib’.  If not, then it should indeed be ‘-next’.

> Well, what do people think about this Lars’s patch?
>
> diff --git a/gnu/packages.scm b/gnu/packages.scm
> index 61345f75a9..7e5a6d49c2 100644
> --- a/gnu/packages.scm
> +++ b/gnu/packages.scm
> @@ -356,20 +356,24 @@ (define cache
>             (find-packages-by-name/direct name version))))
>  
>  (define (find-best-packages-by-name name version)
> -  "If version is #f, return the list of packages named NAME with the highest
> -version numbers; otherwise, return the list of packages named NAME and at
> -VERSION."
> +  "If version is #f, return the list of packages named NAME with only
> +packages marked default? or, if none exist, the highest version numbers;
> +otherwise, return the list of packages named NAME and at VERSION."
>    (if version
>        (find-packages-by-name name version)
>        (match (find-packages-by-name name)
>          (()
>           '())
>          ((matches ...)
> -         ;; Return the subset of MATCHES with the higher version number.
> -         (let ((highest (package-version (first matches))))
> -           (take-while (lambda (p)
> -                         (string=? (package-version p) highest))
> -                       matches))))))
> +         ;; Return the subset of MATCHES which are marked default or those with
> +         ;; the higher version number.
> +         (let ((highest (package-version (first matches)))
> +               (default (filter (lambda (p) (assoc-ref (package-properties p) 'default?)) matches)))
> +           (if (not (null? default))
> +               default
> +               (take-while (lambda (p)
> +                             (string=? (package-version p) highest))
> +                           matches)))))))

I’m slightly reluctant because then you can have several packages that
declare themselves as “default”, which looks weird.  Reasoning about why
a given package was chosen would now involve more than version strings.

Thoughts?

Ludo’.

Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> Thoughts?

What if package variables in Guix were functions that accepted an
optional argument?

Each function could deliver any available version or a default, possibly
accompanied by a warning when the wanted version was not available.

Kind regards
Felix Lechner

Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Simon Tournier]

Hi Ludo,

On mar., 17 janv. 2023 at 17:09, Ludovic Courtès <ludo@gnu.org> wrote:

>> For other cases, such issue is avoided by appending the suffix -next to
>> package name; as with ghc-next, python-numpy-next, emacs-next, etc.
>>
>> Personally, I find the -next trick useful because the package name
>> reflects that it is not the default.  However, it can be annoying to
>> update manifest files when this -next is becoming default.
>
> To me it’s mostly a packaging issue: I would expect ‘ocaml’ to be able
> to use ‘ocaml-ppxlib’.  If not, then it should indeed be ‘-next’.

Currently, yes it is a packaging issue.  And yes, the usual trick to fix
the issue is to append -next to the package name.  As I have tried to
explain in bug#60200 [1]. ;-)

About this -next, Lars’s answer is, quoting [2]:

        The -next suffix has the obvious disadvantage that
        specifications may become invalid as we move -next to the
        “regular” package. So maybe marking packages “default” like the
        attached patch does could improve the current situation. Not
        just for gcc, but also Haskell and Python come to mind.

Hence this discussion. :-)

The addition of a ’properties’ to make the difference between “current”
and “next” packages appears to be a cleaner fix than to append -next to
package name.

Consider the manifest:

    (specifications->manifest (list "ghc-next@9.2"))

and note that currently the Haskell compiler used by
haskell-build-system is ghc@8.10.7.

When this default is updated to an higher version of GHC, says version
9.4, then this manifest breaks because ghc-next@9.2 is renamed ghc@9.2;
the -next suffix is only applied to version higher than the one used by
the Haskell build system.


1: <http://issues.guix.gnu.org/msgid/86wn6nynp1.fsf@gmail.com>
2: <http://issues.guix.gnu.org/msgid/Y6LQs9+in964glaz@noor.fritz.box>


> I’m slightly reluctant because then you can have several packages that
> declare themselves as “default”, which looks weird.  Reasoning about why
> a given package was chosen would now involve more than version strings.

As similarly we can have several packages that declare themselves with
the same name and version. :-)

If we go for -next, then the two packages gcc-toolchain@{11,12} must be
renamed gcc-toolchain-next@{11,12} to be compliant and fixes bug#60200.


Why a given package was chosen as “default”?  Because the packages
marked as “default” are – if and only if several versions are publicly
declared – the ones used by the build-systems and also the ones with
many dependents as Numpy.  It avoids the -next dance.

Well, all in all this “default” property appears to me more elegant than
append -next to package name.

Cheers,
simon