Re: usage of pypi-uri in the pypi importer

[zimoun]

Dear,

On Tue, 27 Oct 2020 at 18:04, Malte Frank Gerdes <malte.f.gerdes@gmail.com> 
wrote:

>> (package
>>   (name "python-pyinstrument-cext")
>>   (version "0.2.2")
>>   (source
>>     (origin
>>       (method url-fetch)
>>       (uri (pypi-uri "pyinstrument-cext" version))
>>       (sha256
>>         (base32
>>           "0nycf7nhx2xzba49m8208agx5xghzxkma3iim5f43h3l3pvjb7pj"))))
>>   (build-system python-build-system)
>>   (home-page
>>     "https://github.com/joerick/pyinstrument_cext";)
>>   (synopsis
>>     "A CPython extension supporting pyinstrument")
>>   (description
>>     "A CPython extension supporting pyinstrument")
>>   (license #f))
>
> The problem here is: if you take that generated package definition as-is -
> and add it to guix - then it will fail to download the sources because
> the actual package name is `pyinstrument_cext' (notice the
> underscore!). Efraim suggested to me tha ti should change that. This
> works. 

Yes.  It happens all the time.  I do not see what is the problem.  You
just have to do:

       (uri (pypi-uri "pyinstrument_cext" version))


For example, the upstream names of the CRAN or Bioconductor packages are
a big mess and do not fit –at all– the names in Guix.  That’s fine.

Let take an example:

    (name "r-matrix-utils")
[..]    
       (method url-fetch)
       (uri (cran-uri "Matrix.utils" version))
[..]
    (properties `((upstream-name . "Matrix.utils")))

And note the extra “upstream-name” property eases stuff, e.g., comment
in the ’r-build-system’:

         ;; R package names are case-sensitive and cannot be derived from the
         ;; Guix package name.  The exact package name is required as an
         ;; argument to ‘tools::testInstalledPackage’, which runs the tests
         ;; for a package given its name and the path to the “library” (a
         ;; location for a collection of R packages) containing it.


>> BTW, ’pypi-uri’ eases the management of all the packages coming from
>> PyPI.  If the URL of PyPI change or is mirrored, it is easy to switch or
>> add the mirror; otherwise one would have to go package by package.
>> Well, if I understand correctly what you mean.
>
> I see that. I was just wondering why this function exists, because the
> importer itself knows the correct link anyway (it's just ugly because
> it's long, the link i mean :D). But i might be misunderstanding how PyPI
> works here.

It is not only about PyPI and pypy-uri.  And maybe it is not the good
example.  Instead give a look at ’cran-uri’ defined in
’guix/build-system/r.scm’.  It returns the list:

   mirror://cran/src/contrib/<name>_<version>.tar.gz
   mirror://cran/src/contrib/Archive/<name>_<version>.tar.gz

and then ’%mirrors’ in ’guix/download.scm’ provides how the mirrors are
expanded:

      (cran
       ;; Arbitrary mirrors from http://cran.r-project.org/mirrors.html
       ;; This one automatically redirects to servers worldwide
       "http://cran.r-project.org/";
       "http://cran.rstudio.com/";
       "http://cran.univ-lyon1.fr/";
       "http://cran.ism.ac.jp/";
       "http://cran.stat.auckland.ac.nz/";
       "http://cran.mirror.ac.za/";
       "http://cran.csie.ntu.edu.tw/";)

using ’maybe-expand-mirrors’ in ’guix/build/download.scm’.  Therefore,
if the R project decides to change their API to:

  source/contribution/ARCHIVE/<version>-<name>.tar.bz2

then it is only one change about ’cran-uri’ and not replace all the
URLs of all packages in ’gnu/packages/cran.scm’.  And idem if mirrors
are added or removed.

The same logic is applied to PyPI even if the upstream source is only
one URL with no mirror. :-)


Hope that helps,
simon