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

______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Reply via email to