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