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

[Chris Evans]

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?!

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:  ... 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?! 

TIA,

Chris

-- 
Small contribution in our coronavirus rigours: 
https://www.coresystemtrust.org.uk/home/free-options-to-replace-paper-core-forms-during-the-coronavirus-pandemic/

Chris Evans  Visiting Professor, University of Sheffield 

I do some consultation work for the University of Roehampton 
 and other places
but  remains my main Email address.  I have a work web site 
at:
   https://www.psyctc.org/psyctc/
and a site I manage for CORE and CORE system trust at:
   http://www.coresystemtrust.org.uk/
I have "semigrated" to France, see: 
   https://www.psyctc.org/pelerinage2016/semigrating-to-france/ 
   
https://www.psyctc.org/pelerinage2016/register-to-get-updates-from-pelerinage2016/

If you want an Emeeting, I am trying to keep them to Thursdays and my diary is 
at:
   https://www.psyctc.org/pelerinage2016/ceworkdiary/
Beware: French time, generally an hour ahead of UK.

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

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

[Duncan Murdoch]

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:  ... 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

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

[Dirk Eddelbuettel]

On 16 March 2021 at 06:48, Duncan Murdoch wrote:
| On 16/03/2021 5:58 a.m., Chris Evans wrote:
| 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.

More granularly, one of these five workflow spawns nine builds of which the
ones with older R version (3.3, 3.4, 3.5) fail as seen eg for run #3:

https://github.com/cpsyctc/CECPfuns/actions/runs/657501549

Maybe you want to comment out runs for R versions that old, or debug why they
fail. The error shown in R 3.5 (a version soon three years out of date you
are not obliged to care for: CRAN uses only current, previous and next
release) is not something I have seen before:

  ── R CMD build 
─
  * checking for file ‘.../DESCRIPTION’ ... OK
  * preparing ‘CECPfuns’:
  * checking DESCRIPTION meta-information ... OK
  Error in 
parse_Rd("/tmp/RtmpydYbB0/Rbuild4d3e1cce5e37/CECPfuns/man/getCSC.Rd",  : 
Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
  Execution halted
  Error: Error in proc$get_built_file() : Build process failed
  Calls:  ... build_package -> with_envvar -> force -> 
  Execution halted
  Error: Process completed with exit code 1.

Here proce$get_built_file points to `pkgbuild` which is part of a non-CRAN
toolchain.  So this may not be caused by your package -- I can't tell. My
preference is to keep it simpler: I usually get by with one workflow and
generally at most two builds.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

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

[Chris Evans]

Hugely appreciated Duncan.

- Original Message -
> From: "Duncan Murdoch" 
> To: "Chris Evans" , "r-package-devel" 
> 
> Sent: Tuesday, 16 March, 2021 10:48:50
> Subject: Re: [R-pkg-devel] Two (newbie/luser) questions about adding CI to 
> github hosted package

> 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.

OK.  I have removed the TEMPLATES directory and moved .lintr to the package 
root.

I think I am better keeping lintr local and having moved .lintr using

lintr::lint_package()

locally is working fine, flagging up cosmetics I can see are all improvements 
so I
can sort those out without wasting github power.  Which takes to the next stage 
...

> 
> 
>> 
>> 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:  ... 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.

That is so appreciated Duncan. One stupid question: is there a way to run a
workflow other than by making an upload/push (or a pull request)?  

I think I have discovered that the work

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

[Chris Evans]

Brilliant and so obviously correct.  As per response a minute ago to Dirk's 
help, I agree completely and have started moves that look to be in line with
that Dirk.

Apologies for my newbie/luser missteps and huge thanks to you both for your 
inputs.  I'm awed to have had this.

Chris

- Original Message -
> From: "Dirk Eddelbuettel" 
> To: "Duncan Murdoch" 
> Cc: "Chris Evans" , "r-package-devel" 
> 
> Sent: Tuesday, 16 March, 2021 12:45:44
> Subject: Re: [R-pkg-devel] Two (newbie/luser) questions about adding CI to 
> github hosted package

> On 16 March 2021 at 06:48, Duncan Murdoch wrote:
>| On 16/03/2021 5:58 a.m., Chris Evans wrote:
>| 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.
> 
> More granularly, one of these five workflow spawns nine builds of which the
> ones with older R version (3.3, 3.4, 3.5) fail as seen eg for run #3:
> 
> https://github.com/cpsyctc/CECPfuns/actions/runs/657501549
> 
> Maybe you want to comment out runs for R versions that old, or debug why they
> fail. The error shown in R 3.5 (a version soon three years out of date you
> are not obliged to care for: CRAN uses only current, previous and next
> release) is not something I have seen before:
> 
>  ── R CMD build 
> ─
>  * checking for file ‘.../DESCRIPTION’ ... OK
>  * preparing ‘CECPfuns’:
>  * checking DESCRIPTION meta-information ... OK
>  Error in 
> parse_Rd("/tmp/RtmpydYbB0/Rbuild4d3e1cce5e37/CECPfuns/man/getCSC.Rd",
>  :
>Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
>  Execution halted
>  Error: Error in proc$get_built_file() : Build process failed
>  Calls:  ... build_package -> with_envvar -> force -> 
>  Execution halted
>  Error: Process completed with exit code 1.
> 
> Here proce$get_built_file points to `pkgbuild` which is part of a non-CRAN
> toolchain.  So this may not be caused by your package -- I can't tell. My
> preference is to keep it simpler: I usually get by with one workflow and
> generally at most two builds.
> 
> Dirk
> 
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
Small contribution in our coronavirus rigours: 
https://www.coresystemtrust.org.uk/home/free-options-to-replace-paper-core-forms-during-the-coronavirus-pandemic/

Chris Evans  Visiting Professor, University of Sheffield 

I do some consultation work for the University of Roehampton 
 and other places
but  remains my main Email address.  I have a work web site 
at:
   https://www.psyctc.org/psyctc/
and a site I manage for CORE and CORE system trust at:
   http://www.coresystemtrust.org.uk/
I have "semigrated" to France, see: 
   https://www.psyctc.org/pelerinage2016/semigrating-to-france/ 
   
https://www.psyctc.org/pelerinage2016/register-to-get-updates-from-pelerinage2016/

If you want an Emeeting, I am trying to keep them to Thursdays and my diary is 
at:
   https://www.psyctc.org/pelerinage2016/ceworkdiary/
Beware: French time, generally an hour ahead of UK.

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

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

[Stefan McKinnon Høj-Edwards]

Hi everybody,

I would like to take a minute to address the language used in the initial
e-mail, notably the "newbie/luser" terminology.
It was given in both the subject (" Two (newbie/luser) questions") as well
as the body ("...  robust R package that might be useful (mainly to R
newbies/lusers of even lower R/programming skills than mine).").

Personally I find the term "luser" (as of a "loser user") very
condescending, whether it is about yourself (because you are not an
experienced programmer) or others (because you perceive them as
inexperienced programmers).
To put it short, using such a condescending term inhibits yourself and,
especially, others. Its use is simply unwarranted. Using the term about the
users of your package, regardless of their experience, is derogatory.

If you are writing to this mailing list with issues developing an
R-package, you are neither a newbie nor a loser, and we collectively will
do our best to help you. So no need in derograting yourself.

Kind regards,
Stefan

Den tir. 16. mar. 2021 kl. 14.05 skrev Chris Evans :

> Hugely appreciated Duncan.
>
> - Original Message -
> > From: "Duncan Murdoch" 
> > To: "Chris Evans" , "r-package-devel" <
> r-package-devel@r-project.org>
> > Sent: Tuesday, 16 March, 2021 10:48:50
> > Subject: Re: [R-pkg-devel] Two (newbie/luser) questions about adding CI
> to github hosted package
>
> > 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.
>
> OK.  I have removed the TEMPLATES directory and moved .lintr to the
> package root.
>
> I think I am better keeping lintr local and having moved .lintr using
>
> lintr::lint_package()
>
> locally is working fine, flagging up cosmetics I can see are all
> improvements so I
> can sort those out without wasting github power.  Which takes to the next
> stage ...
>
> >
> >
> >>
> >> 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:  ... 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
> >> checki

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

[Georgi Boshnakov]

>  ── R CMD build 
> ─
>  * checking DESCRIPTION meta-information ... OK
> Error in 
> parse_Rd("/tmp/RtmpydYbB0/Rbuild4d3e1cce5e37/CECPfuns/man/getCSC.Rd",  : 
>   Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
> Execution halted
> Error: Error in proc$get_built_file() : Build process failed
>  Calls:  ... build_package -> with_envvar -> force -> 
>  Execution halted
 > Error: Process completed with exit code 1.

The error seems to be in building the documentation. There used to be a buglet 
in older versions of R, 
that caused some errors in processing to cause this kind of uninformative 
message from low level code. 
I don't remember the R version but the time frame seems consistent. 
It may well be that some \Sexpr code is spread over more than one line, which 
sometimes threw errors, sometimes silently ignored the lines after the first.

Maybe it's easiest just to require R >= "more recent version.

Georgi Boshnakov


-Original Message-
From: R-package-devel  On Behalf Of Dirk 
Eddelbuettel
Sent: 16 March 2021 12:46
To: Duncan Murdoch 
Cc: r-package-devel 
Subject: Re: [R-pkg-devel] Two (newbie/luser) questions about adding CI to 
github hosted package


On 16 March 2021 at 06:48, Duncan Murdoch wrote:
| On 16/03/2021 5:58 a.m., Chris Evans wrote:
| 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.

More granularly, one of these five workflow spawns nine builds of which the 
ones with older R version (3.3, 3.4, 3.5) fail as seen eg for run #3:

https://github.com/cpsyctc/CECPfuns/actions/runs/657501549

Maybe you want to comment out runs for R versions that old, or debug why they 
fail. The error shown in R 3.5 (a version soon three years out of date you are 
not obliged to care for: CRAN uses only current, previous and next
release) is not something I have seen before:

  ── R CMD build 
─
  * checking for file ‘.../DESCRIPTION’ ... OK
  * preparing ‘CECPfuns’:
  * checking DESCRIPTION meta-information ... OK
  Error in 
parse_Rd("/tmp/RtmpydYbB0/Rbuild4d3e1cce5e37/CECPfuns/man/getCSC.Rd",  : 
Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
  Execution halted
  Error: Error in proc$get_built_file() : Build process failed
  Calls:  ... build_package -> with_envvar -> force -> 
  Execution halted
  Error: Process completed with exit code 1.

Here proce$get_built_file points to `pkgbuild` which is part of a non-CRAN 
toolchain.  So this may not be caused by your package -- I can't tell. My 
preference is to keep it simpler: I usually get by with one workflow and 
generally at most two builds.

Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

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

[Chris Evans]

Thanks. That's very kind and at some levels I know it's correct and I should 
not go there. I have been on the receiving end of some (mostly one) incredibly 
brutal public battering 
in relation to R so perhaps I am lightly scarred by that! 

> From: "Stefan McKinnon Høj-Edwards" 
> To: "Chris Evans" 
> Cc: "Duncan Murdoch" , "r-package-devel"
> 
> Sent: Tuesday, 16 March, 2021 13:22:53
> Subject: Re: [R-pkg-devel] Two (newbie/luser) questions about adding CI to
> github hosted package

> Hi everybody,

> I would like to take a minute to address the language used in the initial
> e-mail, notably the "newbie/luser" terminology.
> It was given in both the subject (" Two (newbie/luser) questions") as well as
> the body ("... robust R package that might be useful (mainly to R
> newbies/lusers of even lower R/programming skills than mine).").

> Personally I find the term "luser" (as of a "loser user") very condescending,
> whether it is about yourself (because you are not an experienced programmer) 
> or
> others (because you perceive them as inexperienced programmers).
> To put it short, using such a condescending term inhibits yourself and,
> especially, others. Its use is simply unwarranted. Using the term about the
> users of your package, regardless of their experience, is derogatory.

> If you are writing to this mailing list with issues developing an R-package, 
> you
> are neither a newbie nor a loser, and we collectively will do our best to help
> you. So no need in derograting yourself.

> Kind regards,
> Stefan

> Den tir. 16. mar. 2021 kl. 14.05 skrev Chris Evans < [
> mailto:chrish...@psyctc.org | chrish...@psyctc.org ] >:

>> Hugely appreciated Duncan.

>> - Original Message -
>>> From: "Duncan Murdoch" < [ mailto:murdoch.dun...@gmail.com |
>> > murdoch.dun...@gmail.com ] >
>>> To: "Chris Evans" < [ mailto:chrish...@psyctc.org | chrish...@psyctc.org ] 
>>> >,
>>> "r-package-devel" < [ mailto:r-package-devel@r-project.org |
>> > r-package-devel@r-project.org ] >
>> > Sent: Tuesday, 16 March, 2021 10:48:50
>>> Subject: Re: [R-pkg-devel] Two (newbie/luser) questions about adding CI to
>> > github hosted package

>> > 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/ | 
 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.

>> OK. I have removed the TEMPLATES directory and moved .lintr to the package 
>> root.

>> I think I am better keeping lintr local and having moved .lintr using

>> lintr::lint_package()

>> locally is working fine, flagging up cosmetics I can see are all 
>> improvements so
>> I
>> can sort those out without wasting github power. Which takes to the next 
>> stage
>> ...




>> >> 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-infor

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

[Duncan Murdoch]

On 16/03/2021 9:04 a.m., Chris Evans wrote:

Hugely appreciated Duncan.

- Original Message -

From: "Duncan Murdoch" 

 ...


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.


That is so appreciated Duncan. One stupid question: is there a way to run a
workflow other than by making an upload/push (or a pull request)?


If you have something like this in your yaml file:

# Controls when the action will run.
on:

  pull_request:
branches: [ master ]

  workflow_dispatch:


then it says the workflow will run when there is a pull request to the 
master branch, and also on request (that's what "workflow_displatch:" 
means).  You can leave out the "pull_request:" lines and only run on 
request.


To actually make the request, you go onto your Github site, go to the 
Actions page, then pick one of the workflows from the list on the left.
If it has "workflow_dispatch" in the file, you'll see a "Run workflow" 
button appear on the right.  It's actually a drop down box; you can 
choose to use the workflow from a different branch by choosing it from 
the list.


Something I'm not sure about is whether choosing a workflow from a 
different branch also selects your package code from that branch, or 
whether you have to choose that on the main Code page.  Experiment, it's 
free!




I think I have discovered that the workflows are controlled by the yaml files
in .github/workflows so I have deleted all except R-CMD-check.yaml and I think
that when I now commit and push this that should delete the other workflows
on github and trigger this one to run.  If you could look at that one then
that would be hugely appreciated.  I see it says:

 strategy:
   fail-fast: false
   matrix:
 config:
   - {os: macOS-latest,   r: 'release'}
   - {os: windows-latest, r: 'release'}
   - {os: windows-latest, r: '3.6'}
   - {os: ubuntu-18.04,   r: 'devel', rspm: 
"https://packagemanager.rstudio.com/cran/__linux__/bionic/latest";, http-user-agent: 
"R/4.0.0 (ubuntu-18.04) R (4.0.0 x86_64-pc-linux-gnu x86_64 linux-gnu) on GitHub Actions" 
}
   - {os: ubuntu-18.04,   r: 'release', rspm: 
"https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
   - {os: ubuntu-18.04,   r: 'oldrel',  rspm: 
"https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
   - {os: ubuntu-18.04,   r: '3.5', rspm: 
"https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
   - {os: ubuntu-18.04,   r: '3.4', rspm: 
"https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
   - {os: ubuntu-18.04,   r: '3.3', rspm: 
"https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}


Some questions as I, I think, make some progress:

1) Why is windows-latest pointing at 3.6?  I am on 4.0.4 locally for windows.  
I assume this is because I have copied or pulled in
a template that is out of date.  Can I just replace that '3.6' with 'release'


I think so.


2) My guts say that at this point it is sensible for me to test against devel, 
release and oldrel but that after the next
release I could stop testing against oldrel?  Is that sensible?


This really depends on your audience.  It looks like the script you have 
came from the tidyverse people; they try to support 4 releases before 
the current one.  That's pretty extreme, you don't really need all 
those.  But I'd leave oldrel in place.  There are definitely lots of 
people out there who haven't updated to 4.0.x yet, for various reasons, 
e.g. not being admin on their computer.




3) I see tests against 3.3, 3.4 and 3.5 there for ubuntu 18.04 and no 20.04.  
Am I correct that I could replace the above
with this:

 strategy:
   fail-fast: false
   matrix:
 config:
   - {os: macOS-latest,   r: 'release'}
   - {os: windows-latest, r: 'release'}
   - {os: windows-latest, r: 'release'}
   - {os: ubuntu-18.04,   r: 'devel', rspm: 
"https://packagemanager.rstudio.com/cran/__linux__/bionic/latest";, http-user-agent: 
"R/4.0.0 (ubuntu-18.04) R (4.0.0 x86_64-pc-linux-gnu x86_64 linux-gnu) on GitHub Actions" 
}
   - {os: ubuntu-18.04,   r: 'release', rspm: 
"https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
   - {os: ubuntu-18.04,   r: 'oldrel',  rspm: 
"https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
   - {os: ubuntu-20.04,   r: 'devel', rspm: 
"https://packagemanager.rstudio.com/cran/__linux__/xenial/latest"}
   - {os: ubuntu-20.04,   r: 'release', rspm: 
"https://packagemanager.rstudio.com/cran/__linux__/xenial/latest"}
   - {os: ubuntu-20.04,   r: 'oldrel', rspm: 
"https://packagemanager.rstudio.com/cran/__linux__/xenial/latest"}

[I have changed the windows '3.6' to 'release' and the last three ubuntu calls 
to 2

[R-pkg-devel] Rcmd check and sourcing URL issues

[Andrew Simmons]

Hello,


I am the maintainer of this.path
, and as you can see
from the CRAN
checks ,
it flags a NOTE that package testthat
 is undeclared in the R
documentation references. this.path allows an R script to know its own path
(from 'RStudio', 'RGui', the command-line, and when using 'source' or any
source equivalents), and I recently added functionality to this.path when
using testthat::source_file. However, I don't know how to go about
declaring package testthat such that I can use it reference it in the R
documentation WITHOUT forcing testthat to load or attach itself when
this.path is loaded or attached (I don't want to declare testthat is the
Imports or Depends field of the DESCRIPTION file).

Another issue related to this.path and base::source, but the fix for this
is more opinionated than the above. If someone sources a URL which contains
a call to this.path, should this.path:
* skip that source call and look for the next available path (which may or
may not exist)
* throw an error that this.path is incompatible when sourcing URLs
* return the URL from that source call

Any help is greatly appreciated, thank you!


Regards,
Andrew Simmons

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Rcmd check and sourcing URL issues

[Duncan Murdoch]

On 16/03/2021 2:02 p.m., Andrew Simmons wrote:

Hello,


I am the maintainer of this.path
, and as you can see
from the CRAN
checks ,
it flags a NOTE that package testthat
 is undeclared in the R
documentation references. this.path allows an R script to know its own path
(from 'RStudio', 'RGui', the command-line, and when using 'source' or any
source equivalents), and I recently added functionality to this.path when
using testthat::source_file. However, I don't know how to go about
declaring package testthat such that I can use it reference it in the R
documentation WITHOUT forcing testthat to load or attach itself when
this.path is loaded or attached (I don't want to declare testthat is the
Imports or Depends field of the DESCRIPTION file).


Declaring it in Suggests sounds appropriate here.  Just make sure that 
your code works (perhaps with limited functionality) if testthat is not 
installed.  You do this by wrapping all uses in tests, e.g.


if (requireNamespace("testthat", quietly = TRUE)) {
   do something with testthat
} else
   do something else.




Another issue related to this.path and base::source, but the fix for this
is more opinionated than the above. If someone sources a URL which contains
a call to this.path, should this.path:
* skip that source call and look for the next available path (which may or
may not exist)
* throw an error that this.path is incompatible when sourcing URLs
* return the URL from that source call


No opinion.

Duncan Murdoch

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

[R-pkg-devel] Problem installing package on windows platforms

[pikappa . devel]

Dear all,
in the latest version of the check results for package diseq (see here)
I get
Version: 0.1.5Check: whether package can be installedResult:
ERRORInstallation failed.See
'd:/Rcompile/CRANpkg/local/4.0/diseq.Rcheck/00install.out'Flavor: r-
release-windows-ix86+x86_64 During the development phase of version
0.1.5, I had checked the package on windows platforms and I had no
problem. When I try to take a look into the details:
https://www.r-project.org/nosvn/R.check/r-release-windows-ix86+x86_64/diseq-00install.html
it seems that the link is dead. I have tried to replicate the problem
using win-builder and rhub but the package is installed successfully
there.

Would you have any suggestions on how to further investigate the
problem?

Thanks in advance!
Best regards,Pantelis

 

[[alternative HTML version deleted]]

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