Ludovic Courtès <ludo@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.

>> * Makefile.am (MODULES): Add new files and remove 'guix/snix.scm'.
>> * guix/scripts/import.scm (%default-options, %options): Delete.
>>   (importers): New variable.
>>   (show-help): List importers.
>>   (guix-import): Factor out Nix-specific logic.  Delegate to correct importer
>>   based upon first argument.
>
> Make sure to adjust tests/snix.scm.
>
> Also, it’d be cool to have tests for (guix import pypi), at least for
> the part that is concerned with parsing JSON and producing a package
> object.
>

Done.

>> +(define tarball-url->string-append
>> +  (let ((tar.gz-regex (make-regexp "\\.tar\\.gz$"))
>> +        (tarball-regex (make-regexp ".*-(.*)\\.tar\\.gz")))
>> +    (lambda (url name version)
>> +      "Return a `string-append' s-expression used for building a generic form
>> +of URL for the package NAME where VERSION is replaced by a `version'
>> +variable."
>
> This is similar to what snix has, and i think it should be shared (see
> below.)
>
>> +(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.

>> +(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.