David Thompson <dthomps...@worcester.edu> skribis: > Ludovic Courtès <l...@gnu.org> writes: > >> I wonder if there may be shared options between all the importers >> (like an option for import & live build.) >> >> That can still be addressed by exporting an option list from (guix >> scripts import), like (guix scripts build) does, I think. >> > > Done. Added an empty options list for now. To avoid circular > dependencies, I had to lazily resolve the importer procedures in > guix/scripts/import.scm.
Yes, and it’s probably a good idea to do like this anyway, so that (guix scripts import) doesn’t really have to know about the existing importers. [...] >>> +(define (make-pypi-sexp name version source-url home-page synopsis >>> + description license) >>> + "Return the `package' s-expression for a python package with the given >>> NAME, >> >> Namely, what do you think of having importers return directly a >> ‘package’ object? Then there could be a shared ‘package->sexp’ >> procedure, that would to the fancy ‘string-append’ thing like above. >> >> And, eventually, we can add an option to do live builds of the generated >> package objects. >> >> That can also be done in the next iteration, though. >> > > I think this is best saved for another patch since it involves modifying > the snix code. I agree that it is a good idea. OK. >>> +(define (factorize-uri uri version) >>> + "Factorize URI, a package tarball URI as a string, such that any >>> occurrences >>> +of the string VERSION is replaced by the symbol 'version." >> >> This one from snix is redundant with ‘tarball-url->string-append’ (and >> maybe less sophisticated?). >> > > 'factorize-uri' is better, so I'm using that now. I created a new > module '(guix import utils)' for commonly used import procedures. > > New patch attached. Perfect, OK to push! Ludo’.
