Hi, On Sun, 25 Oct 2020 at 23:50, Lulu <[email protected]> wrote: > I just sent in a patch to fix this for the pypi importer, although > ideally we'd want versioning support for all importers with a uniform > syntax.
The uniform syntax is ’@’. However, it is importer by importer (case by case) since the external API is different. AFAIU. Speaking about “guix import pypi”, the “--recursive” options still ungracefully fails; even with you patch. > I poked and prodded at the RubyGems API to see if it can do what PyPI > can. It's unfortunately much more limited: API v1 provides a method > for querying all versions of a gem [1] and v2 provides a method for > querying specific versions of a gem [2], although neither of them > provides information about dependency versions, so we can't rely on it > for recursive imports (since it would try to import latest versions of > all dependencies). There's a method that fetches dependency and > versioning info for all versions of all given gems but (probably due > to the verbosity of JSON/YAML) it's in binary Ruby serialisation > format [3]. I can try to hack a parser that surgically extracts > dependency info from a given gem version. What do you think? > > ELPA runs into a similar problem in that it provides tarballs/files > for older versions but dependency info is only provided in the repo > file. (MELPA tries to directly peg all packages to their respective > Git repos' trunks.) > > I presume it's much simpler with the gnu importer, as it's only a > matter of pointing the FTP fetch in the right direction, although I > couldn't confirm it, as the gnu importer doesn't work for me since my > ISP blocks PGP keyserver ports. > > I need to take a closer look at CRAN, CPAN, TeXLive and opam. Hum? You are discussing this bug [1], right? So please could you discuss overthere. 1: <http://issues.guix.gnu.org/issue/44115> All the best, simon
