Hi Pjotr,
thanks for the patches!
I’m glad that you found the recursive importer helpful. Unfortunately,
it doesn’t do a great job with licenses: some of the packages have a
list of GPLv2+ and GPLv3+. Sometimes this is really just a CRAN
expansion for “GPLv2 or later”, other times it means that different
parts of the package are under different licenses.
Could you please check what the license list means for r-rgtk2 and
r-cairodevice? In some cases we can replace the list with a single
license; in other cases we add a comment above the license field to
state what it really means.
Generally, I would recommend putting these packages in (gnu packages
cran) instead of (gnu packages statistics). I’ve been moving packages
from statistics.scm to cran.scm to avoid circular dependencies between
modules.
Here some more comments and questions about the patches:
* the importer unfortunately still defaults to generating HTTP URLs for
the home page instead of HTTPS. It also fails to add a trailing slash
for cran.r-project.org URLs. Could you please add them? (This keeps
the linter happy.)
* the description of many R packages on CRAN don’t use full sentences,
whereas for Guix we’d like to use complete sentences. The easiest way
to fix this is to add “This package provides” to the beginning of the
package description from CRAN. (The importer does this automatically,
when the description begins with “A ”, but it can’t easily guess other
instances where this would be appropriate.)
* the synopses of R packages from CRAN often use … “creative” letter
casing. Instead of, say, “R Bindings for Gtk 2.8.0 and Above” we
would use “R bindings for Gtk 2.8.0 and above”. (I don’t know how to
let the importer do the right thing automatically.)
* for r-cairodevice we might be able to run the tests after setting up
an X server in a pre-check build phase. We would need to add
("xorg-server" ,xorg-server) to the native inputs. Here’s an example
for the phase taken from the caja package:
* the description in r-cairodevice includes references to code: we
would, for example, replace “arbitrary GdkDrawable or Cairo context”
with “arbitrary @code{GdkDrawable} or @code{Cairo} context”. Same
with “RGtk2” and “getGraphicsEvent()”.
* I would replace the description of “r-gwidgets” with this text:
"gWidgets provides a toolkit-independent API for building
interactive GUIs. At least one of the toolkit implementations for
a specific GUI backend (such as @code{gWidgetsRGtk2}) should be
installed."
* In r-gwidgetsrgtk2 we might be able to do without patching the
DESCRIPTION and NAMESPACE files by adding a pre-check phase as shown
above. Is there another reason for patching this file?
* I would change the r-gwidgetsrgtk2 description to this (taken from the
package documentation):
“This package allows the gWidgets API to use the RGtk2 package
allowing the use of the GTK libraries within R.”
* r-igraph already exists in (gnu packages graph).
* r-rqda uses sources from a git checkout, which means that you could
use git-specific helpers:
(version (git-version "0.3-1" revision commit))
…
(file-name (git-file-name name version))
Note that the revision is just a Guix-internal number (as a string)
starting at "1".
* r-nlp: the same applies as for other packages: please add it to
cran.scm, use HTTPS and a trailing slash for the home-page field, use
lower case for the synopsis, and expand the description to a complete
sentence.
* r-tm looks fine to me.
To generate patches more easily you can create one local commit per
package and then use git format-patch -5 to create 5 patch files for the
last 5 commits. We usually apply one patch per package.
--
Ricardo
