R devel - Jan 2020 - R package builder silently continues after unclosed brace

If you start a function in one file but don't close it, the package
will still build if you manage to close it in a later file. Like so:

a.R
b.R
c.R

a.R:
function_a <- function(){
  print("this is function_a")
}

b.R:
function_b <- function(){
  print("unclosed function_b")
# no closing }

c.R:
function_c <- function(){
  print("function_c will be part of function_b")
}
#extra closing } to close function_b
}

--------

The package builder will import `a.R` and `b.R`. And because
function_b was never closed, `c.R` gets subsumed into function_b. It's
pretty hard to debug, and it means that a production implementation
depends on the file structure never changing. (If you define a
function across `b.R` and `d.R`, you can never add an R script that
starts with `c`.)

What's the benefit of letting functions be defined across files in the
package builder? Or is it an unintended side effect?

I suspect the code for all this is in:
/src/library/tools/R/build.R

but it's beyond me.

The command I ran is:
"C:\Program Files\R\R-3.6.2\bin\x64\Rcmd.exe" build
"c:\path\to\package"

Try R check or the source function:

---- (From R check)
> R CMD check testpkg
R CMD check testpkg
* using log directory 'c:/proj/shared/testpkg.Rcheck'
* using R version 3.6.0 (2019-04-26)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file 'testpkg/DESCRIPTION' ... OK
* this is package 'testpkg' version '0.1.0'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking whether package 'testpkg' can be installed ... ERROR
Installation failed.
See 'c:/proj/shared/testpkg.Rcheck/00install.out' for details.
* DONE
Status: 1 ERROR

---- (From 00install.out)

* installing *source* package 'testpkg' ...
** using staged installation
** R
Error in parse(outFile) :
  c:/proj/shared/testpkg/R/b.R:4:0: unexpected end of input
2:   print("unclosed function_b")
3: # no closing }
  ^
ERROR: unable to collate and parse R files for package 'testpkg'
* removing 'c:/proj/shared/testpkg.Rcheck/testpkg'

---- (from the source function)

source ("c:/proj/shared/testpkg/R/b.R", echo=TRUE)
Error in source("c:/proj/shared/testpkg/R/b.R", echo = TRUE) :
  c:/proj/shared/testpkg/R/b.R:4:0: unexpected end of input
2:   print("unclosed function_b")
3: # no closing }

R CMD build does not actually run any R code, it just puts the files
together into a .tar.gz archive.

R CMD INSTALL will run the R code, and fail.

Gabor

On Sat, Jan 25, 2020 at 4:59 PM Andy Manka <andy.manka at gmail.com>
wrote:
>
>
> If you start a function in one file but don't close it, the package
> will still build if you manage to close it in a later file. Like so:
>
> a.R
> b.R
> c.R
>
> a.R:
> function_a <- function(){
>   print("this is function_a")
> }
>
> b.R:
> function_b <- function(){
>   print("unclosed function_b")
> # no closing }
>
> c.R:
> function_c <- function(){
>   print("function_c will be part of function_b")
> }
> #extra closing } to close function_b
> }
>
> --------
>
> The package builder will import `a.R` and `b.R`. And because
> function_b was never closed, `c.R` gets subsumed into function_b. It's
> pretty hard to debug, and it means that a production implementation
> depends on the file structure never changing. (If you define a
> function across `b.R` and `d.R`, you can never add an R script that
> starts with `c`.)
>
> What's the benefit of letting functions be defined across files in the
> package builder? Or is it an unintended side effect?
>
> I suspect the code for all this is in:
> /src/library/tools/R/build.R
>
> but it's beyond me.
>
> The command I ran is:
> "C:\Program Files\R\R-3.6.2\bin\x64\Rcmd.exe" build
"c:\path\to\package"
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

On 1/25/20 12:55, G?bor Cs?rdi wrote:
> R CMD build does not actually run any R code,
**unless** the package contains dynamic vignettes and/or dynamic man 
pages (e.g. man pages that include \Sexpr macros), in which case 'R CMD 
build' first installs the package in order to evaluate the dynamic stuff 
and then puts all the files together in a .tar.gz archive (including the 
evaluated vignette and man pages).

Just wanted to clarify.

Best,
H.
> it just puts the files
> together into a .tar.gz archive.
> 
> R CMD INSTALL will run the R code, and fail.
> 
> Gabor
> 
> On Sat, Jan 25, 2020 at 4:59 PM Andy Manka <andy.manka at gmail.com>
wrote:
>>
>>
>> If you start a function in one file but don't close it, the package
>> will still build if you manage to close it in a later file. Like so:
>>
>> a.R
>> b.R
>> c.R
>>
>> a.R:
>> function_a <- function(){
>>    print("this is function_a")
>> }
>>
>> b.R:
>> function_b <- function(){
>>    print("unclosed function_b")
>> # no closing }
>>
>> c.R:
>> function_c <- function(){
>>    print("function_c will be part of function_b")
>> }
>> #extra closing } to close function_b
>> }
>>
>> --------
>>
>> The package builder will import `a.R` and `b.R`. And because
>> function_b was never closed, `c.R` gets subsumed into function_b.
It's
>> pretty hard to debug, and it means that a production implementation
>> depends on the file structure never changing. (If you define a
>> function across `b.R` and `d.R`, you can never add an R script that
>> starts with `c`.)
>>
>> What's the benefit of letting functions be defined across files in
the
>> package builder? Or is it an unintended side effect?
>>
>> I suspect the code for all this is in:
>> /src/library/tools/R/build.R
>>
>> but it's beyond me.
>>
>> The command I ran is:
>> "C:\Program Files\R\R-3.6.2\bin\x64\Rcmd.exe" build
"c:\path\to\package"
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=EooPdH2zxyGemkIijLeOEhTnbHj2ZnF752zkuL2oH78&s=k7-iYyWapTxOuYwiVvt93bBNtx_2FjuXZYP-Ids9ypU&e>
> ______________________________________________
> R-devel at r-project.org mailing list
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=EooPdH2zxyGemkIijLeOEhTnbHj2ZnF752zkuL2oH78&s=k7-iYyWapTxOuYwiVvt93bBNtx_2FjuXZYP-Ids9ypU&e>
-- 
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fredhutch.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319