[R-pkg-devel] Two (newbie/luser) questions about adding CI to github hosted package

Duncan Murdoch murdoch@dunc@n @end|ng |rom gm@||@com
Tue Mar 16 11:48:50 CET 2021

On 16/03/2021 5:58 a.m., Chris Evans wrote:
> I would be very grateful of help as I seem to be making very heavy weather of all the intricacies of creating a
> robust R package that might be useful (mainly to R newbies/lusers of even lower R/programming skills than mine).
> I am making a lot of progress and am awed by the work so many have put in to make things possible: huge gratitude
> to too many to name. However, I seem to be hitting a wall on adding CI to my package.
> 1) I am sure that linting my package will help me but there are some defaults in lintr/superlinter that I am want
> to take a personal stand and not use: allowing myself not always to use perfect camelCase because I think it will
> confuse my end users and the line length limit which at the default of 80 seems to me, on a modern set up, to make
> my code far less readable than if I allow some long lines. My problem is that I am failing to work out how to override
> the defaults. I thought that putting in /TEMPLATES/.lintr in my package directory and having it contain:
> # linters: with_defaults(object_usage_linter = NULL)
> linters: with_defaults(
>    line_length_linter(120),
>    cyclocomp_linter(25),
>    object_name_linter = NULL
>    )
> would override the defaults (I'm working on the cyclocomp complaint!)  Can anyone, perhaps looking at my
> https://github.com/cpsyctc/CECPfuns/ package, tell me what I'm doing wrong and how to get it right?!

I use lintr, and put my .lintr file in the main directory of the package.

> 2) I work on a machine running Ubuntu 20.04 in Rstudio and everything checks and tests fine there but I wanted
> to use the github actions to check the package out on Windows and Mac and, rather more by luck I think than really
> understanding how I got there, I seem to have achieved that.  Rather bizarrely, the code (it's only R source)
> passes on Windows and Mac but fails in the Ubuntu test systems with errors like:
> ── R CMD build ─────────────────────────────────────────────────────────────────
> * checking for file ‘.../DESCRIPTION’ ... OK
> * preparing ‘CECPfuns’:
> * checking DESCRIPTION meta-information ... OK
> * installing the package to process help pages
>        -----------------------------------
> * installing *source* package ‘CECPfuns’ ...
> ** using staged installation
> ** R
> ** inst
> ** byte-compile and prepare package for lazy loading
> Error in dyn.load(file, DLLpath = DLLpath, ...) :
>    unable to load shared object '/home/runner/work/_temp/Library/stringi/libs/stringi.so':
>    libicui18n.so.55: cannot open shared object file: No such file or directory
> Calls: <Anonymous> ... namespaceImport -> loadNamespace -> library.dynam -> dyn.load
> Execution halted
> ERROR: lazy loading failed for package ‘CECPfuns’
> I _think_ these are just changes in the stirngi package that seem to failing on the test machine
> and OK on my machine. That made me think that I can see a lot of logic in my checking things on
> the various default versions of R in Ubuntu 16.04, Windows and MacOS but perhaps it is unnecessary
> and wasting resources to check the release version of R on Ubuntu 20.04 as it seems safe enough to
> assume that the package built on my local machine in the release version of R and on Ubuntu 20.04
> that fails like this will only be transient (or that successes on my machine will only be ... but
> at least I'll see them and not waste github resources!)
> The catch is that I am baffled by how to configure github actions to change the lint defaults and
> to change the selection of releases and platforms.  I think that may because I may have created
> a mess in my github actions workflows.
> Would anyone be willing to help or even to look at it and point me to the explanations I am failing
> to find?!

You have 5 workflows, and their current content doesn't appear to match 
the results on your actions page.  Pick one, run it, and I'll see if I 
can spot the reason for a failure.

Duncan Murdoch

More information about the R-package-devel mailing list