From: zimoun <zimon.toutoune@gmail.com>
To: Malte Frank Gerdes <malte.f.gerdes@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: usage of pypi-uri in the pypi importer
Date: Tue, 27 Oct 2020 22:58:22 +0100 [thread overview]
Message-ID: <86sg9z2uwx.fsf@gmail.com> (raw)
In-Reply-To: <86mu07lhwx.fsf@gmail.com>
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
prev parent reply other threads:[~2020-10-27 21:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-17 19:17 usage of pypi-uri in the pypi importer Malte Frank Gerdes
2020-10-26 15:22 ` zimoun
2020-10-27 17:04 ` Malte Frank Gerdes
2020-10-27 21:58 ` zimoun [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86sg9z2uwx.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=guix-devel@gnu.org \
--cc=malte.f.gerdes@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).