Re: [PATCH] import: Add PyPI importer.

[Ludovic Courtès]

David Thompson <address@hidden> skribis:

> Ludovic Courtès <address@hidden> 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’.