[bug#38408] [PATCH v4 1/6] gnu: added new function, find-packages-by-name*/direct

[Ludovic Courtès]

Hi Martin,

Sorry for the late reply.

Martin Becze <address@hidden> skribis:

>> Providing an explicit cache bypassing method also sounds worrying to me:
>> the cache is supposed to be transparent and semantics-preserving.
>> 
>> More generally, I think adding new features to an importer shouldn’t
>> require modifications in this area, as a matter of separating concerns.
>> 
>> WDYT?
>> 
>> Thanks,
>> Ludo’.
>
> yes I agree, I removed that in the last version! Which also rebases off
> the new topological sort procedure. I'll attach the latest patches here,
> in case you missed it.

Thanks!

> From eeffdf569c4d7fbfd843e0b48404b6a2f3d46343 Mon Sep 17 00:00:00 2001
> From: Martin Becze <address@hidden>
> Date: Mon, 16 Dec 2019 17:08:16 -0500
> Subject: [PATCH v5 1/4] guix: import: added recusive-import-semver
>
> * guix/import/utils.scm (recusive-import-semver): New Varible
> * guix/import/utils.scm (package->definition)[arguments]: Add append-verions 
> option

[...]

> +(define* (recursive-import-semver #:key
> +                                  name
> +                                  (range "*")
> +                                  name->metadata
> +                                  metadata->package
> +                                  metadata-versions
> +                                  package-dependencies
> +                                  dependency-name
> +                                  dependency-range
> +                                  guix-name
> +                                  make-sexp)
> +  "Generates a list of package expressions for the dependencies of the given 
> +NAME and version RANGE. The dependencies will be resolved using semantic 
> versioning.
> +This procedure makes the assumption that most package repositories will, for 
> a
> +given package provide some <metadata> on that package that includes what
> +versions of the package that are available and a list of dependencies for 
> each
> +version. Dependencies are assumed to be composed of a NAME, a semantic RANGE 
> and
> +other data.
> +
> +This procedure takes the following keys:
> +  NAME - The name of the package to import
> +  RANGE - The version range of the package to import
> +  NAME->METADATA - A procedure that takes a NAME of a package and returns 
> that
> +package's <metadata>
> +  METADATA->PACKAGE A procedure that takes a package's <metadata> and 
> VERSION 
> +and returns the <package> for the given VERSION
> +  METADATA-VERSIONS A procedure that that takes a packages <metadata> and
> +returns a list of version as strings that are available for the given package
> +  PACKAGE-DEPENDENCIES a procedure that returns a list of <dependency> given 
> a 
> +<package>
> +  DEPENDENCY-NAME A procedure that takes a <dependency> and returns the its 
> name
> +  DEPENDENCY-RANGE A procedure that takes a <dependency> and returns that
> +decency's range as a string
> +  GUIX-NAME A procedure that take a NAME and returns the Guix version of it
> +  MAKE-SEXP A procedure that takes <metadata>, <package> and a list of pairs
> +containing (EXPORT-NAME <dependency>), returning the package expression as 
> an 
> +s-expression"

As noted in my previous message, I think this interface is too complex,
and since it’s used in a single importer, it would be best to have it
directly in (guix import crate).

If/when there’s a need to share that logic among several importers, then
we can look for ways to factorize whatever needs to be factorized.

In the meantime, there are probably semver-related things that could
naturally to a helper (guix import semver) module, although perhaps most
of that is already provided by guile-semver?

> +  (define-record-type <node-dependency>

Also, as a rule of thumb, we wouldn’t want to duplicate these data types
and related code.

WDYT?

Thanks,
Ludo’.