package updater: operate on package structs, not names?

package updater: operate on package structs, not names?

[Ricardo Wurmus]

Hi Guix,

I noticed a flaw in the CRAN updater.  The ‘latest-release’ procedure is
called with the result of ‘(package-name package)’.  The problem here is
that Guix package names follow much stricter naming rules than the
upstream packages.

Here are a couple of examples of R package names and their related Guix
package names:

    GenomicRanges —> r-genomic-ranges
    data.table    —> r-data-table
    formatR       –> r-formatr
    DBI           —> r-dbi

When we only pass the Guix name to ‘latest-release’, the updater won’t
know how to find the package and its upstream version because the names
don’t match.

There are two ways to approach this: we change the Guix package names to
closely match those of the upstream packages, or we pass the complete
package structure to ‘latest-release’.  The latter approach would allow
the CRAN updater to extract the appropriate name from the tarball URI.

We have the same problem for Ruby gems, I think, so I think that it
generally would be a good idea to pass the whole package object to
‘latest-release’.  Those updaters that only need the package name can
just reduce it by calling ‘(package-name package)’ themselves.

What do you think?

~~ Ricardo

Re: package updater: operate on package structs, not names?

[Ricardo Wurmus]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

> Hi Guix,
>
> I noticed a flaw in the CRAN updater.  The ‘latest-release’ procedure is
> called with the result of ‘(package-name package)’.  The problem here is
> that Guix package names follow much stricter naming rules than the
> upstream packages.
>
> Here are a couple of examples of R package names and their related Guix
> package names:
>
>     GenomicRanges —> r-genomic-ranges
>     data.table    —> r-data-table
>     formatR       –> r-formatr
>     DBI           —> r-dbi
>
> When we only pass the Guix name to ‘latest-release’, the updater won’t
> know how to find the package and its upstream version because the names
> don’t match.
>
> There are two ways to approach this: we change the Guix package names to
> closely match those of the upstream packages, or we pass the complete
> package structure to ‘latest-release’.  The latter approach would allow
> the CRAN updater to extract the appropriate name from the tarball URI.
>
> We have the same problem for Ruby gems, I think, so I think that it
> generally would be a good idea to pass the whole package object to
> ‘latest-release’.  Those updaters that only need the package name can
> just reduce it by calling ‘(package-name package)’ themselves.
>
> What do you think?

It just occurred to me that I could do something like this:

   (specification->package the-package-name)

and then operate on the package.  Then I noticed that
‘guix/import/pypi.scm’ does this already.  Since we start out with a
package object wouldn’t it be better to just keep it rather than convert
back and forth between names and packages?

~~ Ricardo

Re: package updater: operate on package structs, not names?

[Andreas Enge]

On Tue, Dec 01, 2015 at 11:41:25AM +0100, Ricardo Wurmus wrote:
> There are two ways to approach this: we change the Guix package names to
> closely match those of the upstream packages, or we pass the complete
> package structure to ‘latest-release’.  The latter approach would allow
> the CRAN updater to extract the appropriate name from the tarball URI.

I think we should work on the package, or more concretely, the uri and
the version. Then we should do some pattern matching to find occurrences
of major-minor-patchlevel, major-minor or major versions in the uri.
And then we should try +1 in each of them (with later components set to 0).

For instance with qt:
    (version "5.5.1")
             (uri
               (string-append
                 "http://download.qt.io/official_releases/qt/"
                 (version-major+minor version)
                 "/" version
                 "/single/qt-everywhere-opensource-src-"
                 version ".tar.xz"))
which expands to
http://download.qt.io/official_releases/qt/5.5/5.5.1/single/qt-everywhere-opensource-src-5.5.1.tar.xz

we should try
http://download.qt.io/official_releases/qt/5.5/5.5.2/single/qt-everywhere-opensource-src-5.5.2.tar.xz
http://download.qt.io/official_releases/qt/5.6/5.6.0/single/qt-everywhere-opensource-src-5.6.0.tar.xz
http://download.qt.io/official_releases/qt/6.0/6.0.0/single/qt-everywhere-opensource-src-6.6.0.tar.xz
(and maybe some recursion to find the latest version).

What do you think?

Andreas

Re: package updater: operate on package structs, not names?

[Ludovic Courtès]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> There are two ways to approach this: we change the Guix package names to
> closely match those of the upstream packages, or we pass the complete
> package structure to ‘latest-release’.  The latter approach would allow
> the CRAN updater to extract the appropriate name from the tarball URI.

This sounds like a good idea; I don’t think there are any good reasons
for just passing the package name.  Could you do that?

If need be, some of the CRAN packages could have a special property:

  (package
    (name "r-foo")
    ;; …
    (properties `((upstream-name . "Fo0"))))

Ludo’.