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