all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Xinglu Chen <public@yoctocell.xyz>
To: Alice BRENON <alice.brenon@ens-lyon.fr>
Cc: 49958@debbugs.gnu.org
Subject: [bug#49958] [PATCH] More flexibility in opam importer
Date: Fri, 13 Aug 2021 15:13:14 +0200	[thread overview]
Message-ID: <87h7fth4id.fsf@yoctocell.xyz> (raw)
In-Reply-To: <20210813131109.14c25204@ens-lyon.fr>

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

On Fri, Aug 13 2021, Alice BRENON wrote:

> Le Fri, 13 Aug 2021 09:37:43 +0200,
> Xinglu Chen <public@yoctocell.xyz> a écrit :
>
>> On Tue, Aug 10 2021, Alice BRENON wrote:
>> 
>> […]
>> > include: +
>> > +By default, packages are searched in the official OPAM repository.
>> >  This +option, which can be used more than once, lets you add other
>> > +repositories where to look for packages.  
>> 
>> “lets you add other repositories where to look for package” sounds a
>> bit weird, maybe
>> 
>>   lets you add other repositories which will be used to lookup
>> packages.
>> 
>> ?
>
> Ok, as discussed on IRC, trying "lets you add other repositories which
> will be searched for packages".
>
>
>> What happens if I specify an additional repository, and a package
>> exists in that repository _and_ the default opam repository?  From
>> which repository will the package be imported from?
>
> That is the beauty of it: the repositories are assumed to be passed by
> order of preference, defaulting to the official opam repositories only
> if packages haven't been found anywhere else. Writing this makes me
> realize that indeed, starting with --repo=opam isn't entirely
> redundant: it could be used to prevent an otherwise interesting repo
> from overriding stuff if opam already provides it (let's assume some
> "super-opam" with a couple additional packages, and custom versions of
> existing opam packages).
>
> Calling `--repo=super-opam` would use the super-opam versions as soon
> as a package exists in super-opam, while `--repo=opam
> --repo=super-opam` would take the super-opam versions only when none
> exist in opam.
>
> A much simpler use-case would be to locally override only some
> packages in a repo, and pass --repo=overriden-repo --repo=normal-repo.
>
> This behaviour relies on the implementation of opam-fetch and how folds
> work in guile.
>
> Since in the importer script options are stacked as they are retrieved
> from the CLI arguments, and repositories are then just filter-maped from
> that list, they end up in a list by reverse order of preference. In
> opam->guix-package, 'opam gets push on the top if it's not already
> there somewhere. So what we get as input of opam-fetch is a list of
> repositories-specs by reverse order of preference. Now fold applies the
> accumulator to each item in order, so, last elements has the final say,
> i.e. the last elements which yield results in find-latests are
> preferred over the earlier elements of the list. This works for the
> same reason why `(lambda (l) (fold cons '() l)` will reverse its input
> list. It's slightly inefficient because it means all repositories are
> searched, in reverse order of preference, but I haven't figured how to
> get a lazy fold in guile. Granted, I could have written the recursion
> explicitly to get that. Will fix if performance matters.
>
> Also, versions are not compared between repositories, as soon as a repo
> provides one version of a given package, the latest of all the versions
> this one provides is used in the output, no matter the contents of
> other repositories. This is useful to allow "downgrades" by masking
> parts of repository which have too recent versions.
>
> So, thanks for your remark, the documentation deserved a clearer
> explanation of it.

Thanks for the explanation!  And great that you also documented this to
avoid ambiguity.

>> > -(define (latest-version versions)
>> > -  "Find the most recent version from a list of versions."
>> > -  (fold (lambda (a b) (if (version>? a b) a b)) (car versions)
>> > versions)) +(define (get-version-and-file path)
>> > +  "Analyse a candidate path and return an list containing
>> > information for proper
>> > +  version comparison as well as the source path for metadata."
>> > +  (and-let* ((metadata-file (string-append path "/opam"))
>> > +             (filename (basename path))
>> > +             (version (string-join (cdr (string-split filename
>> > #\.)) ".")))
>> > +    (and (file-exists? metadata-file)
>> > +         (eq? 'regular (stat:type (stat metadata-file)))
>> > +         (if (string-prefix? "v" version)
>> > +             `(V ,(substring version 1) ,metadata-file)
>> > +             `(digits ,version ,metadata-file)))))  
>> 
>> What happens if some other prefix is used, e.g., “release-” or “V-”?
>> 
>
> It would get marked as a 'digit. In a previous draft before I started
> sending this series of patches, it was called 'R, standing for
> "regular", then I thought it was not very meaningful, and, since the
> versions were to my knowledge supposed to be either v[0-9]+(\.[0-9]+)*
> or [0-9]+(\.[0-9]+)*, I thought I could call that default case "digits"
> to clearly indicate what I was trying to refer to. I could change it to
> 'other if it matters too much, but the important thing here is that we
> distinguish between v-prefixed (the so-called "janestreet
> re-versionning" mentioned inside the implementation of find-latest on
> current d87d6d6 master) and other versions because ⬇️

Oh, OK, I wasn’t aware of this “janestreet re-versionning” thing, so
only janestreet package have the “v” prefix, right?  That explains why
versions prefixed with “v” are always greater than those not prefixed
with anything (in ‘keep-max-version’).

>> Also, why not just return the version number and the metadata file; we
>> don’t really care about the prefix do we?
>> 
>
> yes we do ! the former latest-version finder handled strings, and
> dropped this prefix or put it back on the fly, but the logic
> implemented was: if there are v-prefixed versions, find the greatest of
> them, without the initial "v", if there aren't, just find the greatest
> of all versions. This implies that v-prefixed versions are considered
> more important and automatically greater than non-prefixed versions, no
> matter what the numbers, which is why this information must be kept.

Ah, understood.

> I'm just playing ADTs in guile here, "parsing" the version string only
> once to retain a symbolic representation of it that will at first
> glance allow to identify the type of version used and access the
> relevant digits for comparison. The comparison is used right after:
>
>> > +(define (keep-max-version a b)
>> > +  "Version comparison on the lists returned by the previous
>> > function taking the
>> > +  janestreet re-versioning into account (v-prefixed come first)."
>> > +  (match (cons a b)
>> > +    ((('V va _) . ('V vb _)) (if (version>? va vb) a b))
>> > +    ((('V _ _) . _) a)
>> > +    ((_ . ('V _ _)) b)
>> > +    ((('digits va _) . ('digits vb _)) (if (version>? va vb) a
>> > b)))) 
>
> and used in the reduce in find-latest-version. So keeping this 'V is
> what will help janestreet-re-versionned packages "skip the line" by
> being automatically greater than any non v-prefixed package (thus,
> v0.0.1 is greater than 13.2, which is the current behaviour).
>
>> >  (define (find-latest-version package repository)
>> >    "Get the latest version of a package as described in the given
>> > repository."
>> > -  (let* ((dir (string-append repository "/packages/" package))
>> > -         (versions (scandir dir (lambda (name) (not
>> > (string-prefix? "." name))))))
>> > -    (if versions
>> > -      (let ((versions (map
>> > -                        (lambda (dir)
>> > -                          (string-join (cdr (string-split dir
>> > #\.)) "."))
>> > -                        versions)))
>> > -        ;; Workaround for janestreet re-versionning
>> > -        (let ((v-versions (filter (lambda (version)
>> > (string-prefix? "v" version)) versions)))
>> > -          (if (null? v-versions)
>> > -            (latest-version versions)
>> > -            (string-append "v" (latest-version (map (lambda
>> > (version) (substring version 1)) v-versions))))))
>> > -      (begin
>> > -        (format #t (G_ "Package not found in opam repository:
>> > ~a~%") package)
>> > -        #f))))
>> > +  (let ((packages (string-append repository "/packages"))
>> > +        (filter (make-regexp (string-append "^" package "\\."))))
>> > +    (reduce keep-max-version #f
>> > +            (filter-map
>> > +             get-version-and-file
>> > +             (find-files packages filter #:directories? #t)))))
>> >  
>> […]
>> > +            (filter-map get-opam-repository repositories-specs))
>> > +      (leave (G_ "Package '~a' not found~%") name)))  
>> 
>> Nit: I wouldn’t capitalize “package”, otherwise the error message
>> looks like this
>> 
>>   guix import: error: Package 'equations' not found
>
> a very neat tip, thank you ! : )

You are welcome, and thank you for working on this!

> From cde8b2a5d88d89bfea31c86d3ae94d37c1d3c83f Mon Sep 17 00:00:00 2001
> From: Alice BRENON <alice.brenon@ens-lyon.fr>
> Date: Sat, 7 Aug 2021 19:50:10 +0200
> Subject: [PATCH] guix: opam: More flexibility in the importer.
>
> * guix/scripts/import/opam.scm: pass all instances of --repo as a list
>   to the importer.

Nit: The word after the “:” is usually capitalized, so “Pass” instead of
“pass” in this case.  Sorry for not noticing this earlier; the person
committing the patch can probably fixup the commit message, so no need
to send a reroll just for this small fix.  :-)

> * guix/import/opam.scm (opam-fetch): stop expecting "expanded"
>   repositories and call get-opam-repository instead to keep values
>   "symbolic" as long as possible and factorize.
>   (get-opam-repository): use the same repository source as CLI opam does
>   (i.e. HTTP-served index.tar.gz instead of git repositories).
>   (find-latest-version): be more flexible on the repositories structure
>   instead of expecting packages/PACKAGE-NAME/PACKAGE-NAME.VERSION/.
> * tests/opam.scm: update the call to opam->guix-package since repo is
>   now expected to be a list and remove the mocked get-opam-repository
>   deprecated by the support for local folders by the actual
>   implementation.
> * doc/guix.texi: document the new semantics and valid arguments for the
>   --repo option.
> ---
>  doc/guix.texi                |  30 +++++--
>  guix/import/opam.scm         | 158 +++++++++++++++++++++--------------
>  guix/scripts/import/opam.scm |   8 +-
>  tests/opam.scm               |  68 ++++++++-------
>  4 files changed, 160 insertions(+), 104 deletions(-)
>
> diff --git a/doc/guix.texi b/doc/guix.texi
> index 78c1c09858..2d36561186 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -94,6 +94,7 @@ Copyright @copyright{} 2021 Xinglu Chen@*
>  Copyright @copyright{} 2021 Raghav Gururajan@*
>  Copyright @copyright{} 2021 Domagoj Stolfa@*
>  Copyright @copyright{} 2021 Hui Lu@*
> +Copyright @copyright{} 2021 Alice Brenon@*
>  
>  Permission is granted to copy, distribute and/or modify this document
>  under the terms of the GNU Free Documentation License, Version 1.3 or
> @@ -11612,14 +11613,31 @@ Traverse the dependency graph of the given upstream package recursively
>  and generate package expressions for all those packages that are not yet
>  in Guix.
>  @item --repo
> -Select the given repository (a repository name).  Possible values include:
> +
> +By default, packages are searched in the official OPAM repository.  This
> +option, which can be used more than once, lets you add other
> +repositories which will be searched for packages.  It accepts as valid
> +arguments:
> +
>  @itemize
> -@item @code{opam}, the default opam repository,
> -@item @code{coq} or @code{coq-released}, the stable repository for coq packages,
> -@item @code{coq-core-dev}, the repository that contains development versions of coq,
> -@item @code{coq-extra-dev}, the repository that contains development versions
> -      of coq packages.
> +@item the name of a known repository - can be one of @code{opam},
> +      @code{coq} (equivalent to @code{coq-released}),
> +	  @code{coq-core-dev}, @code{coq-extra-dev} or @code{grew}.
> +@item the URL of a repository as expected by the @code{opam repository
> +      add} command (for instance, the URL equivalent of the above
> +	  @code{opam} name would be @uref{https://opam.ocaml.org}).
> +@item the path to a local copy of a repository (a directory containing a
> +      @file{packages/} sub-directory).
>  @end itemize
> +
> +Repositories must be passed to this option by order of preference and do
> +not replace the default @code{opam} which is always failed-back to.

I suggest

  Repositories should be passed to this option by the order of
  preference.  The additional repositories will not replace the default
  @code{opam} repository, which is always kept as a fallback.

WDYT?

> +Also, please note that versions are not compared accross repositories.
> +The first repository (from left to right) that has at least one version
> +of a given package will prevail over any others and the version imported
                                                  ^
Missing comma.

The rest looks good!  :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

  reply	other threads:[~2021-08-13 13:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-09 12:04 [bug#49958] [PATCH] More flexibility in opam importer Alice BRENON
     [not found] ` <handler.49958.B.16285213978219.ack@debbugs.gnu.org>
2021-08-09 15:19   ` Alice BRENON
2021-08-10 12:04     ` Alice BRENON
2021-08-10 16:48       ` Alice BRENON
2021-08-13  7:37         ` Xinglu Chen
2021-08-13 11:11           ` Alice BRENON
2021-08-13 13:13             ` Xinglu Chen [this message]
2021-08-13 13:47               ` Alice BRENON
2021-08-20 22:07                 ` bug#49958: " Julien Lepiller

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h7fth4id.fsf@yoctocell.xyz \
    --to=public@yoctocell.xyz \
    --cc=49958@debbugs.gnu.org \
    --cc=alice.brenon@ens-lyon.fr \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.