okkkie! finally got this rewote! Patches attached.
> 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).
This is now done!
> 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?
guile-semver is pretty easy to work with so I didn't need to use
many helpers. The one I did use I think I will try to submit to
guile-semver itself.
On 12/27/19 1:38 PM, Ludovic Courtès wrote:
> Hi Martin,
>
> Sorry for the late reply.
>
> Martin Becze <mjbecze@riseup.net> 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 <mjbecze@riseup.net> 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’.