From: "Ludovic Courtès" <ludo@gnu.org>
To: Simon Tournier <zimon.toutoune@gmail.com>
Cc: Guix Devel <guix-devel@gnu.org>, Lars-Dominik Braun <lars@6xq.net>
Subject: Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)
Date: Tue, 17 Jan 2023 17:09:16 +0100 [thread overview]
Message-ID: <87v8l5dtxv.fsf@gnu.org> (raw)
In-Reply-To: <86pmbk3hci.fsf@gmail.com> (Simon Tournier's message of "Wed, 11 Jan 2023 22:13:17 +0100")
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’.
next prev parent reply other threads:[~2023-01-17 16:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Y6LQs9+in964glaz@noor.fritz.box>
2023-01-11 21:13 ` properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages) Simon Tournier
2023-01-12 6:22 ` Csepp
2023-01-12 9:03 ` pukkamustard
2023-01-17 16:09 ` Ludovic Courtès [this message]
2023-01-17 18:41 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-01-17 18:48 ` Simon Tournier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v8l5dtxv.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=lars@6xq.net \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).