Coder Social home page Coder Social logo

pkgbuild's Introduction

pkgbuild

R-CMD-check Codecov test coverage

The goal of pkgbuild is to make it easy to build packages with compiled code. It provides tools to configure your R session, and check that everything is working ok. If you are using RStudio, it also helps you trigger automatic install of the build tools.

Installation

Install the released version from CRAN

install.packages("pkgbuild")

Or install the development version from GitHub:

# install.packages("pak")
pak::pak("r-lib/pkgbuild")

Example

# Check that you have the build tools installed
pkgbuild::check_build_tools(debug = TRUE)

# Build a package
pkgbuild::build("/path/to/my/package")

# Run your own code in an environment guaranteed to
# have build tools available
pkgbuild::with_build_tools(my_code)

Configuration

DESCRIPTION entries

  • Config/build/clean-inst-doc can be set to FALSE to avoid cleaning up inst/doc when building a source package. Set it to TRUE to force a cleanup. See the clean_doc argument of build() as well.

  • Config/build/copy-method can be used to avoid copying large directories in R CMD build. It works by copying (or linking) the files of the package to a temporary directory, leaving out the (possibly large) files that are not part of the package. Possible values:

    • none: pkgbuild does not copy the package tree. This is the default.
    • copy: the package files are copied to a temporary directory before R CMD build.
    • link: the package files are symbolic linked to a temporary directory before R CMD build. Windows does not have symbolic links, so on Windows this is equivalent to copy.

    You can also use the pkg.build_copy_method option or the PKG_BUILD_COPY_METHOD environment variable to set the copy method. The option is consulted first, then the DESCRIPTION entry, then the environment variable.

  • Config/build/extra-sources can be used to define extra source files for pkgbuild to decide whether a package DLL needs to be recompiled in needs_compile(). The syntax is a comma separated list of file names, or globs. (See ?utils::glob2rx().) E.g. src/rust/src/*.rs or configure*.

Options

  • pkg.build_copy_method: use this option to avoid copying large directories when building a package. See possible values above, at the Config/build/copy-method DESCRIPTION entry.

  • pkg.build_extra_flags: set this to FALSE to to opt out from adding debug compiler flags in compile_dll(). Takes precedence over the PKG_BUILD_EXTRA_FLAGS environment variable. Possible values:

    • TRUE: add extra flags,
    • FALSE: do not add extra flags,
    • "missing": add extra flags if the user does not have a $HOME/.R/Makevars file.
  • pkg.build_stop_for_warnings: if it is set to TRUE, then pkgbuild will stop for R CMD build errors. It takes precedence over the PKG_BUILD_STOP_FOR_WARNINGS environment variable.

Environment variables

  • PKG_BUILD_COLOR_DIAGNOSTICS: set it to false to opt out of colored compiler diagnostics. Set it to true to force colored compiler diagnostics.

  • PKG_BUILD_COPY_METHOD: use this environment variable to avoid copying large directories when building a package. See possible values above, at the Config/build/copy-method DESCRIPTION entry.

  • PKG_BUILD_EXTRA_FLAGS: set this to false to to opt out from adding debug compiler flags in compile_dll(). The pkg.build_extra_flags option takes precedence over this environment variable. Possible values:

    • "true": add extra flags,
    • "false": do not add extra flags,
    • "missing": add extra flags if the user does not have a $HOME/.R/Makevars file.
  • PKG_BUILD_STOP_FOR_WARNINGS: if it is set to true, then pkgbuild will stop for R CMD build errors. The pkg.build_stop_for_warnings option takes precedence over this environment variable.

Code of Conduct

Please note that the pkgbuild project is released with a Contributor Code of Conduct. By contributing to this project, you agree to abide by its terms.

pkgbuild's People

Contributors

ateucher avatar batpigandme avatar burgerga avatar cderv avatar const-ae avatar dgkf avatar dpastoor avatar dpprdan avatar gaborcsardi avatar hadley avatar jeroen avatar jimhester avatar krlmlr avatar lionel- avatar lorenzwalthert avatar michaelchirico avatar musvaage avatar njtierney avatar paleolimbot avatar richfitz avatar richierocks avatar sangeetabhatia03 avatar thegreatwhiteshark avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

pkgbuild's Issues

programmatic control over inst/doc removal in build()

Currently build() will query user on willingness to remove inst/doc if such is present in source. It would be nice to have a parameter of build() that controls this and avoids the interactive query if the parameter is set.

Release pkgbuild 1.0.3

Prepare for release:

  • devtools::check()
  • devtools::check_win_devel()
  • rhub::check_for_cran()
  • revdepcheck::revdep_check(num_workers = 4)
  • Polish NEWS
  • Polish pkgdown reference index

Submit to CRAN:

  • usethis::use_version()
  • Update cran-comments.md
  • devtools::submit_cran()
  • Approve email

Wait for CRAN...

  • Accepted πŸŽ‰
  • usethis::use_github_release()
  • usethis::use_dev_version()
  • Tweet

Provide a hook to set compile flags

Ideally, I would like to set them dynamically, to set the debug level of the C code.

The user sets the DEBUGME environment variable to turn on debugging for some packages, and set their debug level. This could automatically work for C code as well (after recompiling), if I had a way to change the compiler flags.

rtools_path error if cached version does not exist

Hi, it seems on windows (I have not checked on other platforms), that pkgbuild presents an error about rtools_path when calling rtools_path(), if find_rtools() has not been invoked.

pkgbuild::rtools_path()
Error in get(name, envir = cache) : object 'rtools_path' not found
traceback()
3: get(name, envir = cache)
2: cache_get("rtools_path")
1: pkgbuild::rtools_path()
packageVersion("pkgbuild")
[1] β€˜1.0.3’
pkgbuild::find_rtools()
[1] TRUE
pkgbuild::rtools_path()
[1] "c:/Rtools/bin"

> sessioninfo::session_info()
- Session info ---------------------------------------------------------------------------------------------
 setting  value                       
 version  R version 3.6.0 (2019-04-26)
 os       Windows 10 x64              
 system   x86_64, mingw32             
 ui       RStudio                     
 language (EN)                        
 collate  English_United States.1252  
 ctype    English_United States.1252  
 tz       America/New_York            
 date     2019-06-01                  

- Packages -------------------------------------------------------------------------------------------------
 package     * version          date       lib source                            
 assertthat    0.2.1            2019-03-21 [1] CRAN (R 3.6.0)                    
 callr         3.2.0            2019-03-15 [1] CRAN (R 3.6.0)                    
 cli           1.1.0            2019-03-19 [1] CRAN (R 3.6.0)                    
 config        0.3              2018-03-27 [1] CRAN (R 3.6.0)                    
 crayon        1.3.4            2017-09-16 [1] CRAN (R 3.6.0)                    
 devutils      1.4.0.1540209467 2019-05-31 [1] Github (dpastoor/devutils@7bef165)
 magrittr      1.5              2014-11-22 [1] CRAN (R 3.6.0)                    
 packrat       0.5.0            2018-11-14 [1] CRAN (R 3.6.0)                    
 pkgbuild    * 1.0.3            2019-03-20 [1] CRAN (R 3.6.0)                    
 prettyunits   1.0.2            2015-07-13 [1] CRAN (R 3.6.0)                    
 processx      3.3.1            2019-05-08 [1] CRAN (R 3.6.0)                    
 ps            1.3.0            2018-12-21 [1] CRAN (R 3.6.0)                    
 purrr         0.3.2            2019-03-15 [1] CRAN (R 3.6.0)                    
 R6            2.4.0            2019-02-14 [1] CRAN (R 3.6.0)                    
 rlang         0.3.4            2019-04-07 [1] CRAN (R 3.6.0)                    
 rstudioapi    0.10             2019-03-19 [1] CRAN (R 3.6.0)                    
 sessioninfo   1.1.1            2018-11-05 [1] CRAN (R 3.6.0)                    
 withr         2.1.2            2018-03-15 [1] CRAN (R 3.6.0)                    
 yaml          2.2.0            2018-07-25 [1] CRAN (R 3.6.0)                    

[1] C:/Users/devin/Documents/repos/exploration/packrat/lib/x86_64-w64-mingw32/3.6.0
[2] C:/Users/devin/Documents/repos/exploration/packrat/lib-ext/x86_64-w64-mingw32/3.6.0
[3] C:/Users/devin/Documents/repos/exploration/packrat/lib-R/x86_64-w64-mingw32/3.6.0
[4] C:/Users/devin/Documents/repos/exploration/packages/bin

Consider removing the user's ID from tarballs generated by build()

In build(), the ID of the user is automatically inserted into the DESCRIPTION file, e.g.

Packaged: 2018-11-06 14:01:50 UTC; <MY USER ID>

This is problematic for those of us who work in corporate settings. We must not divulge our user IDs in the packages we develop and release.

I feel this problem affects enough users to consider here. In this post, @zeroby0 suggests I decompress, edit, and re-compress the built package. Maybe pkgbuild could handle this, either with an option in build() or an exported function to clean the tarball. Or maybe the right solution is to chat with the R Core Team about R CMD build.

has_compiler is not detecting compiler

I am having a disconnect with the result of has_compiler. Are there some environment variables that need to be set in order for this to work properly?

has_compiler shows false:

> has_compiler()
[1] FALSE

But yet I can install packages from source, for example Rcpp:

> install.packages("Rcpp", type = "source")
trying URL 'https://cran.rstudio.com/src/contrib/Rcpp_1.0.0.tar.gz'
Content type 'application/x-gzip' length 3635277 bytes (3.5 MB)
==================================================
downloaded 3.5 MB

* installing *source* package β€˜Rcpp’ ...
** package β€˜Rcpp’ successfully unpacked and MD5 sums checked
** libs
clang++  -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I../inst/include/  -I/usr/local/include   -fPIC  -Wall -g -O2  -c Date.cpp -o Date.o
clang++  -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I../inst/include/  -I/usr/local/include   -fPIC  -Wall -g -O2  -c Module.cpp -o Module.o
clang++  -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I../inst/include/  -I/usr/local/include   -fPIC  -Wall -g -O2  -c Rcpp_init.cpp -o Rcpp_init.o
clang++  -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I../inst/include/  -I/usr/local/include   -fPIC  -Wall -g -O2  -c api.cpp -o api.o
clang++  -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I../inst/include/  -I/usr/local/include   -fPIC  -Wall -g -O2  -c attributes.cpp -o attributes.o
clang++  -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I../inst/include/  -I/usr/local/include   -fPIC  -Wall -g -O2  -c barrier.cpp -o barrier.o
clang++ -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib -L/usr/local/lib -o Rcpp.so Date.o Module.o Rcpp_init.o api.o attributes.o barrier.o -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
installing to /Library/Frameworks/R.framework/Versions/3.5/Resources/library/Rcpp/libs
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
* DONE (Rcpp)

Session info:

> sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Mojave 10.14.3

Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.0          ps_1.3.0            prettyunits_1.0.2   rprojroot_1.3-2     digest_0.6.18       crayon_1.3.4        withr_2.1.2         assertthat_0.2.0   
 [9] R6_2.3.0            backports_1.1.3     magrittr_1.5        rlang_0.3.1         cli_1.0.1           fs_1.2.6            remotes_2.0.2       testthat_2.0.1     
[17] callr_3.1.1         desc_1.2.0          devtools_2.0.1.9000 tools_3.5.2         glue_1.3.0          pkgload_1.0.2       compiler_3.5.2      processx_3.2.1     
[25] pkgbuild_1.0.2      sessioninfo_1.1.1   memoise_1.1.0       usethis_1.4.0      

Thanks for any suggestions you could provide.

find_rtools() returns true, has_rtools() returns true but unable to build packages from source on Windows.

Hi,

I'm unable to compile any packages from source in Windows, in spite of Rtools being installed and included in PATH variables. While find_rtools() returns TRUE, check_compiler() and check_build_tools() both prompt a dialogue asking me to download Rtools, even though it is already installed at C:\Rtools.

I've tried the following:

  • Add Rtools to path:
    • C:\Rtools\bin
    • C:\Rtools\mingw_64\bin

Some links mentioned the need to set BINPREF in the environment. This is what I placed in my environment:

BINPREF=C:\\Rtools\\mingw_64\\bin\\

After many unsuccessful attempts at fixes from sources across the internet (I can link to everything I've tried if needed), I decided to try and download Rtools from the prompt that appears after pkgbuild::check_compiler(). Now, PATH looks like this:

  • C:\RBuildTools\3.5\bin
  • C:\RBuildTools\3.5\mingw_64\bin
  • C:\Rtools\bin
  • C:\Rtools\mingw_64\bin

After trying pkgbuild::check_compiler() after the newly installed RBuildTools, I'm asked again if I'd like to download Rtools since check_compiler() was unable to find the Rtools that was just installed.

I've tried prepending the C:\Rtools\bin and C:\Rtools\mingw_64\bin at the startup of R by including some extra lines in my .Rprofile:

Sys.setenv(PATH = paste(
    "C:\\RBuildTools\\3.5\\bin",
    "C:\\RBuildTools\\3.5\\mingw_${WIN}\\bin",
    "C:\\Rtools\\bin",
    "C:\\Rtools\\mingw_64\\bin",
    Sys.getenv("PATH"),
    sep = ";"
))
Sys.setenv(BINPREF = "C:\\Rtools\\mingw_64\\bin\\")

Here's a reprex of the output:

...

pkgbuild::has_rtools(TRUE)
#> Scanning R CMD config CC...
#> cc_path: C:\Rtools\mingw_64\bin\gcc 
#> install_path: C:/Rtools 
#> VERSION.txt
#> Rtools version 3.5.0.4 
#> Found compatible gcc from R CMD config CC
#> [1] TRUE
pkgbuild::compiler_flags(TRUE)
#>                            CFLAGS                          CXXFLAGS 
#> "-UNDEBUG -Wall -pedantic -g -O0" "-UNDEBUG -Wall -pedantic -g -O0" 
#>                        CXX11FLAGS                            FFLAGS 
#> "-UNDEBUG -Wall -pedantic -g -O0"                          "-g -O0" 
#>                           FCFLAGS 
#>                          "-g -O0"
pkgbuild::check_build_tools()
pkgbuild::rcmd_build_tools(TRUE)
#>   
   The system cannot find the path specified.
#> 
  
   'TRUE' is not recognized as an internal or external command,
#>    operable program or batch file.
#> 
pkgbuild::setup_rtools(TRUE)
#> Scanning R CMD config CC...
#> cc_path: C:\Rtools\mingw_64\bin\gcc 
#> install_path: C:/Rtools 
#> VERSION.txt
#> Rtools version 3.5.0.4 
#> Found compatible gcc from R CMD config CC
#> [1] TRUE
pkgbuild::check_compiler(TRUE)
#> Trying to compile a simple C file
#> Running "C:/PROGRA~1/R/R-3.5.3/bin/x64/Rcmd.exe" SHLIB foo.c
#> The system cannot find the path specified.
#> C:\Rtools\mingw_64\bin\gcc  -I"C:/PROGRA~1/R/R-3.5.3/include" -DNDEBUG          -O2 -Wall  -std=gnu99 -mtune=generic -c foo.c -o foo.o
#> sh: C:Rtoolsmingw_64bingcc: command not found
#> make: *** [C:/PROGRA~1/R/R-3.5.3/etc/x64/Makeconf:208: foo.o] Error 127
#> Error: Failed to compile C code

Created on 2019-04-19 by the reprex package (v0.2.1)

Here's the output from Sys.getenv():

...

Sys.getenv()
#> __COMPAT_LAYER        RunAsAdmin Installer
#> ALLUSERSPROFILE       C:\ProgramData
#> APPDATA               C:\Users\RRoach\AppData\Roaming
#> BINPREF               C:\Rtools\mingw_64\bin\
#> CALLR_CHILD_R_LIBS    C:/Users/RRoach/Documents/R/win-library/3.5;C:/Program
#>                       Files/R/R-3.5.3/library
#> CALLR_CHILD_R_LIBS_USER
#>                       C:/Users/RRoach/Documents/R/win-library/3.5;C:/Program
#>                       Files/R/R-3.5.3/library
#> ChocolateyInstall     C:\ProgramData\chocolatey
#> CLICOLOR_FORCE        1
#> CLINK_DIR             C:\Program Files (x86)\clink\0.4.8
#> COMMANDER_PATH        C:\Program Files\totalcmd
#> CommonProgramFiles    C:\Program Files\Common Files
#> CommonProgramFiles(x86)
#>                       C:\Program Files (x86)\Common Files
#> CommonProgramW6432    C:\Program Files\Common Files
#> COMPUTERNAME          RROACH-LAT
#> ComSpec               C:\WINDOWS\system32\cmd.exe
#> CYGWIN                nodosfilewarning
#> DISPLAY               :0
#> DriverData            C:\Windows\System32\Drivers\DriverData
#> FOLDER_MARKER_DIR     C:\Program Files (x86)\Folder Marker
#> GFORTRAN_STDERR_UNIT
#>                       -1
#> GFORTRAN_STDOUT_UNIT
#>                       -1
#> GIT_ASKPASS           rpostback-askpass
#> HOME                  C:/Users/RRoach/Documents
#> HOMEDRIVE             C:
#> HOMEPATH              \Users\RRoach
#> I_MPI_ROOT            C:\Program Files
#>                       (x86)\IntelSWTools\compilers_and_libraries_2018.3.210\windows\mpi
#> INTEL_LICENSE_FILE    C:\Program Files (x86)\Common
#>                       Files\Intel\Licenses
#> LOCALAPPDATA          C:\Users\RRoach\AppData\Local
#> LOGONSERVER           \\CORPDC
#> MSMPI_BIN             C:\Program Files\Microsoft MPI\Bin\
#> MSYS2_ENV_CONV_EXCL   R_ARCH
#> npm                   C:\Users\RRoach\AppData\Roaming\npm
#> NUMBER_OF_PROCESSORS
#>                       4
#> OneDrive              C:\Users\RRoach\Documents\OneDrive -
#>                       IMODULES SOFTWARE
#> OneDriveCommercial    C:\Users\RRoach\Documents\OneDrive -
#>                       IMODULES SOFTWARE
#> OPENSSL_CONF          C:\Users\RRoach\scoop\apps\openssl\current\bin\cnf\openssl.cnf
#> OS                    Windows_NT
#> PATH                  C:\RBuildTools\3.5\bin\;C:\RBuildTools\3.5\mingw_64\bin\;C:\Rtools\bin\;C:\Rtools\mingw_64\bin\;C:\RBuildTools\3.5\bin;C:\RBuildTools\3.5\bin\;C:\RBuildTools\3.5\mingw_64\bin\;C:\Rtools\bin\;C:\Rtools\mingw_64\bin\;C:\RBuildTools\3.5\bin\;C:\RBuildTools\3.5\mingw_64\bin\;C:\Rtools\bin\;C:\Rtools\mingw_64\bin\;C:\RBuildTools\3.5\bin;C:\Program
#>                       Files\R\R-3.5.3\bin\x64;C:\RBuildTools\3.5\bin;C:\RBuildTools\3.5\mingw_64\bin;C:\Rtools\bin;C:\Rtools\mingw_64\bin;C:\Program
#>                       Files\MiKTeX 2.9\miktex\bin;C:\Program
#>                       Files\R\R-3.5.3\bin;C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program
#>                       Files\Microsoft MPI\Bin\;C:\Program Files
#>                       (x86)\IntelSWTools\compilers_and_libraries_2018.3.210\windows\mpi\intel64\bin;C:\Program
#>                       Files (x86)\Intel\iCLS Client\;C:\Program
#>                       Files\Intel\iCLS Client\;C:\Program Files
#>                       (x86)\Intel\Intel(R) Management Engine
#>                       Components\DAL;C:\Program
#>                       Files\Intel\Intel(R) Management Engine
#>                       Components\DAL;C:\Program Files
#>                       (x86)\Intel\Intel(R) Management Engine
#>                       Components\IPT;C:\Program
#>                       Files\Intel\Intel(R) Management Engine
#>                       Components\IPT;C:\Program
#>                       Files\PuTTY\;C:\Program Files
#>                       (x86)\Shoreline Communications\ShoreWare
#>                       Client\;C:\Program Files (x86)\Shoreline
#>                       Communications\ShoreWare
#>                       Client\win64;C:\Program Files
#>                       (x86)\Google\Google Apps
#>                       Sync\;C:\WINDOWS\System32\OpenSSH\;C:\Program
#>                       Files\dotnet\;C:\Program Files\Microsoft SQL
#>                       Server\130\Tools\Binn\;C:\ProgramData\chocolatey\bin;C:\Program
#>                       Files\Git\cmd;C:\Program Files
#>                       (x86)\Pandoc\;C:\Program Files\MiKTeX
#>                       2.9\miktex\bin\x64\;C:\Program Files
#>                       (x86)\Microsoft SQL Server\Client
#>                       SDK\ODBC\130\Tools\Binn\;C:\Program Files
#>                       (x86)\Microsoft SQL
#>                       Server\140\Tools\Binn\;C:\Program Files
#>                       (x86)\Microsoft SQL
#>                       Server\140\DTS\Binn\;C:\Program Files
#>                       (x86)\Microsoft SQL
#>                       Server\140\Tools\Binn\ManagementStudio\;C:\Program
#>                       Files\PowerShell\6\;C:\Program
#>                       Files\nodejs\;C:\Users\RRoach\AppData\Roaming\npm;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Users\RRoach\scoop\apps\openssl\current\bin;C:\Users\RRoach\AppData\Local\GitHubDesktop\bin;C:\Users\RRoach\AppData\Local\Programs\Microsoft
#>                       VS
#>                       Code\bin;C:\Users\RRoach\AppData\Local\Microsoft\WindowsApps;C:\Users\RRoach\AppData\Local\Microsoft\WindowsApps;C:\Users\RRoach\AppData\Local\Continuum\miniconda3;C:\Users\RRoach\AppData\Local\Continuum\miniconda3\Scripts
#> PATHEXT               .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
#> PROCESSOR_ARCHITECTURE
#>                       AMD64
#> PROCESSOR_IDENTIFIER
#>                       Intel64 Family 6 Model 142 Stepping 9,
#>                       GenuineIntel
#> PROCESSOR_LEVEL       6
#> PROCESSOR_REVISION    8e09
#> PROCESSX_PS2E386TXRBG_1555694020
#>                       YES
#> ProgramData           C:\ProgramData
#> ProgramFiles          C:\Program Files
#> ProgramFiles(x86)     C:\Program Files (x86)
#> ProgramW6432          C:\Program Files
#> prompt                [RROACH-LAT] $d$s$t$_$p$_$+$g
#> PSModulePath          C:\Program
#>                       Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
#> PUBLIC                C:\Users\Public
#> QT_D3DCREATE_MULTITHREADED
#>                       1
#> R_ARCH                /x64
#> R_BROWSER             false
#> R_COMPILED_BY         gcc 4.9.3
#> R_DOC_DIR             C:/PROGRA~1/R/R-3.5.3/doc
#> R_ENVIRON             C:\Users\RRoach\AppData\Local\Temp\RtmpEV0JgU\file235834f66e2b
#> R_ENVIRON_USER        C:\Users\RRoach\AppData\Local\Temp\RtmpEV0JgU\file235874bb5c1f
#> R_HOME                C:/PROGRA~1/R/R-3.5.3
#> R_LIBS                C:/Users/RRoach/Documents/R/win-library/3.5;C:/Program
#>                       Files/R/R-3.5.3/library
#> R_LIBS_USER           C:/Users/RRoach/Documents/R/win-library/3.5;C:/Program
#>                       Files/R/R-3.5.3/library
#> R_PDFVIEWER           false
#> R_PROFILE             C:\Users\RRoach\AppData\Local\Temp\RtmpEV0JgU\file2358339159e9
#> R_PROFILE_USER        C:\Users\RRoach\AppData\Local\Temp\RtmpEV0JgU\file235879721c8d
#> R_USER                C:/Users/RRoach/Documents
#> RMARKDOWN_MATHJAX_PATH
#>                       C:/Program
#>                       Files/RStudio/resources/mathjax-26
#> RS_LOCAL_PEER         \\.\pipe\25185-rsession
#> RS_RPOSTBACK_PATH     C:/Program Files/RStudio/bin/rpostback
#> RS_SHARED_SECRET      63341846741
#> RSTUDIO               1
#> RSTUDIO_CONSOLE_COLOR
#>                       256
#> RSTUDIO_CONSOLE_WIDTH
#>                       173
#> RSTUDIO_MSYS_SSH      C:/Program
#>                       Files/RStudio/bin/msys-ssh-1000-18
#> RSTUDIO_PANDOC        C:/Program Files/RStudio/bin/pandoc
#> RSTUDIO_SESSION_PORT
#>                       25185
#> RSTUDIO_USER_IDENTITY
#>                       RRoach
#> RSTUDIO_WINUTILS      C:/Program Files/RStudio/bin/winutils
#> RTOOLS40_HOME         C:\rtools40
#> SSH_ASKPASS           rpostback-askpass
#> SystemDrive           C:
#> SystemRoot            C:\WINDOWS
#> TEMP                  C:\Users\RRoach\AppData\Local\Temp
#> TERM                  xterm-256color
#> TMP                   C:\Users\RRoach\AppData\Local\Temp
#> USERDNSDOMAIN         LOCAL.IMODULES.COM
#> USERDOMAIN            LOCAL
#> USERDOMAIN_ROAMINGPROFILE
#>                       LOCAL
#> USERNAME              RRoach
#> USERPROFILE           C:\Users\RRoach
#> VS140COMNTOOLS        C:\Program Files (x86)\Microsoft Visual
#>                       Studio 14.0\Common7\Tools\
#> VS2017INSTALLDIR      C:\Program Files (x86)\Microsoft Visual
#>                       Studio\2017\Community
#> windir                C:\WINDOWS

Created on 2019-04-19 by the reprex package (v0.2.1)

Any help would be greatly appreciated!

check_build_tools doesn't search path in RStudio on Windows

Running check_build_tools works in an basic RTerm environment, but fails when run in RStudio. I've installed RTools in a non-standard place, in my user folder rather than C:\rtools. In RStudio, check_build_tools launches a pop-up asking me to download Rtools. When I click no, I get the error "Error: Could not find tools necessary to compile a package".

I'm using pkgbuild 6574561, RStudio 1.0.153, R 3.4.1 and RTools 3.4.

with_build_tools fails on CRAN when building the prophet package

I have started using pkgbuild internally in rstan, not to build a package but to build dynamic loaded shared objects via inline::cxxfunction. This looks like it will be a big help for Windows users and it is working fine in most cases, including in many packages that depend on rstan.

However, the prophet package maintained by @seanjtaylor and @bletham is the one package that imports rstan that is failing to build on CRAN for all flavors of Windows, with

WARNING: Rtools is required to build R packages, but is not currently installed.
Please download and install Rtools 3.5 from http://cran.r-project.org/bin/windows/Rtools/.
Error: Could not find tools necessary to compile a package

  • removing 'd:/Rcompile/CRANpkg/lib/3.6/prophet'
  • restoring previous 'd:/Rcompile/CRANpkg/lib/3.6/prophet'

For the full-log see, e.g.
https://www.r-project.org/nosvn/R.check/r-devel-windows-ix86+x86_64/prophet-00install.html

The prophet package has an unusual build process that utilizes a src/install_libs.Rfile that calls rstan::stan_model
https://github.com/facebook/prophet/blob/master/R/src/install.libs.R#L14
which ultimately calls pkgbuild::with_build_tools(inline::cxxfunction(...))
https://github.com/stan-dev/rstan/blob/develop/rstan/rstan/R/cxxfunplus.R#L152

But I have no idea why with_build_tools would think RTools is not installed on the Windows server that tests R packages.

Color the output of the compiler

Both gcc and clang support ANSI colored output now, so (if possible) we can force-enable this, if we are sure that the R console supports ANSI colors.

pkg_name result retains trailing whitespace from Package field in DESCRIPTION

Original context: using pkgdown; there was trailing whitespace in the "Package" field that was causing build_reference to fail.

It looks like the desc package behavior is to preserve whitespace on read:
https://github.com/r-lib/desc/blob/898c0cea313f7df17cadfbc81eb38b9b403c6044/tests/testthat/test-read.R#L13

Then should pkgbuild:::pkg_name trim if it is depending on desc to read the DESCRIPTION file (?)

path <- tempdir()

pkg <- "pkgws"

package.skeleton(name = pkg, code_files = "break.R", path = path)
#> Exiting.
#> Creating directories ...
#> Creating DESCRIPTION ...
#> Creating NAMESPACE ...
#> Creating Read-and-delete-me ...
#> Copying code files ...
#> Making help files ...
#> Done.
#> Further steps are described in '/var/folders/xb/hqmfzgl95fq8mx6tjxkzb71r0000gn/T//RtmpldMIW0/pkgws/Read-and-delete-me'.

x <- read.dcf(file.path(path, pkg, "DESCRIPTION"))

x[1, "Package"] <- "pkgws   "

write.dcf(x, file.path(path, pkg, "DESCRIPTION"), keep.white = "Package")

pkgbuild:::pkg_name(file.path(path, "pkgws"))
#> [1] "pkgws   "

read.dcf(file.path(path, pkg, "DESCRIPTION"))[, "Package"]
#> Package 
#> "pkgws"

Obviously, I dropped the whitespace in my DESCRIPTION file, and everything works now. Reporting for you to consider.

Thanks,
Kyle

Release pkgbuild 1.0.4

Prepare for release:

Submit to CRAN:

  • usethis::use_version('patch')
  • devtools::submit_cran()
  • Approve email

Wait for CRAN...

  • Accepted πŸŽ‰
  • usethis::use_github_release()
  • usethis::use_dev_version()

Failure error messages need some hint as to what to do next

e.g

pkg_install("r-lib/pkgdepends")
β„Ή Checking for package metadata updates
βœ” All 10 metadata files are current.                                            
βœ” Using session cached package metadata                                         
βœ” Using cached package metadata                                                 

β„Ή Building pkgdepends 0.0.0.9003                                                
Error: Could not find tools necessary to compile a package

It would be useful to include a hint here:

Error: Could not find tools necessary to compile a package
Call `pkgbuild::check_build_tools(TRUE)` to diagnose the problem.

pkgbuild 1.0.2

Prepare for release:

  • devtools::check_win_devel()
  • rhub::check_for_cran()
  • revdepcheck::revdep_check(num_workers = 4)
  • Polish NEWS
  • If new failures, update email.yml then revdepcheck::revdep_email_maintainers()

Perform release:

  • Create RC branch (for bigger releases)
  • Bump version (in DESCRIPTION and NEWS)
  • devtools::check_win_devel() (again!)
  • devtools::submit_cran()
  • Approve email

Wait for CRAN...

  • Tag release
  • pkgdown::build_site()
  • Merge RC back to master branch
  • Bump dev version
  • Write blog post
  • Tweet
  • Add link to blog post in pkgdown news menu

Template from r-lib/usethis#338

Fix configure/cleanup execute bit?

If you download a tar.gz package and then install it, the builtin tar implementation (!) fixes the execute permissions for the configure / cleanup files: https://github.com/wch/r-source/blob/5b2f6807839f2970051f6723040a27bb97a49c81/src/library/utils/R/tar.R#L470

This is in tar, not in untar, so it happens when R is tarring up a built package.

This is sometimes a problem, e.g. when you download a zip repo archive from GitHub, which does not have executable bits, and the R package has dynamic manual pages. In this case R tries to install the package before building it (!), and fails if configure is not executable.

I am not sure why but R CMD build --no-manual does not help, either:

❯ R CMD build --no-manual  r-lib-ps-7d17711
* checking for file β€˜r-lib-ps-7d17711/DESCRIPTION’ ... OK
* preparing β€˜ps’:
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to process help pages
      -----------------------------------
* installing *source* package β€˜ps’ ...
ERROR: 'configure' exists but is not executable -- see the 'R Installation and Administration Manual'
* removing β€˜/private/var/folders/59/0gkmw1yj2w7bf2dfc3jznv5w0000gn/T/Rtmp4TcYrg/Rinst1667631fb8710/ps’
      -----------------------------------
ERROR: package installation failed

So my question is, should pkgbuild try to fix up the configure and cleanup files at the beginning? I think this would make sense, certainly more sense than fixing them in the tar implementation.

Cannot Build with Rtools installed in Documents folder

I can't install Rtools on C: because of restrictions in my corporate environment. I am having trouble running rstan due to the build tools not being recognized. I tried the Stan forums first, but they redirected me to open an issue with pkgbuild as it seems to be the source.

https://discourse.mc-stan.org/t/rstan-always-trying-to-download-rtools-when-its-already-installed/7682/12

pkgbuild::with_build_tools("print(β€œhello”)", debug = TRUE)
#> Scanning R CMD config CC...
#> cc_path:  
#> '.exe' does not exist
#> Scanning path...
#> Scanning registry...
#> Found C:/Users/josephdean/Documents/Rtools for 3.5 
#> VERSION.txt
#> Rtools version 3.5.0.4
#> [1] "print(β€œhello”)"

Created on 2019-02-14 by the reprex package (v0.2.1)

Rtools 3.5 can work with R 3.3.* and up

The check that pkgbuild issues during the devtools::check() routine is too restrictive because Rtools 3.5 works with R 3.4. For details, please see the Rtools page:

https://cran.r-project.org/bin/windows/Rtools/

The affected code can be found here:

pkgbuild/R/rtools.R

Lines 49 to 64 in fb45340

if (!is.null(from_path)) {
# Installed
if (is.null(from_path$version)) {
# but not from rtools
if (debug)
cat("gcc and ls on path, assuming set up is correct\n")
return(TRUE)
} else {
# Installed, but not compatible
message("WARNING: Rtools ", from_path$version, " found on the path",
" at ", from_path$path, " is not compatible with R ", getRversion(), ".\n\n",
"Please download and install ", rtools_needed(), " from ", rtools_url,
", remove the incompatible version from your PATH.")
return(invisible(FALSE))
}
}

Should we handle tar.gz files in build()?

Especially for binary = TRUE, because R CMD INSTALL can handle a source tar.gz nicely.

Related to this, we could have a check_build_tools = TRUE argument, that defaults to "auto", but e.g. pkgman could set this smartly, based on the NeedsCompilation field. AFAICT the only reason to look inside the archive is to check if compilation is needed.

devtools::build() deletes inst/doc

Dear package authors,
I almost lost documents because devtools::build() deletes inst/doc.
Yes I know that devtools::build() in interactive mode warns me (Are you sure? Yes/No),
but no, if I say 'No' the build is interupted, and if I say 'Yes' I lose documents. Worse, in certain settings (triggering build in Rstudio) there is no warning but a silent deletion. I would expect devtools::build() to behave as R CMD build, which does not remove any sources it is packing into the build.
Best regards
Jens OehlschlΓ€gel

Warn users RTools is _not_ appropriately configured if not in system PATH variable

The find_rtools() feature is problematic because if Rtools is detected within the registry it indicates that Rtools has been installed correctly. However, this makes the critical assumption that every time a new session is created find_rtools() is run to re-register the location of Rtools as find_rtools only performs a per session modification. Many users, when they go to compile code in an R session or RMarkdown documents encounter an issue as a result. Examples:

Proposed solution: Add a warning after Line 111 in rtools.R containing:

message("WARNING: Rtools was not found on the system PATH.\n\n",
        "However, there was a valid entry for Rtools in the registry.\n\n",
        "As a result, Rtools will only be available on a per-session basis after",
        "running find_rtools.\n\n",
        "Please download and reinstall ", rtools_needed(), " from ", rtools_url,".\n\n"
        "Make sure to add Rtools to your PATH!")

Release v1.0.1

Prepare for release:

  • devtools::check_win_devel()
  • rhub::check_for_cran()
  • revdepcheck::revdep_check(num_workers = 4)
  • Polish NEWS
  • If new failures, update email.yml then revdepcheck::revdep_email_maintainers()

Perform release:

  • Create RC branch (for bigger releases)
  • Bump version (in DESCRIPTION and NEWS)
  • devtools::check_win_devel() (again!)
  • devtools::submit_cran()
  • pkgdown::build_site()
  • Approve email

Wait for CRAN...

  • Tag release
  • Merge RC back to master branch
  • Bump dev version
  • Write blog post
  • Tweet
  • Add link to blog post in pkgdown news menu

Template from r-lib/usethis#338

--resave-data argument to the build function gets overwritten internally

Unless the binary argument was set to TRUE, the build() function automatically appends the --no-resave-data flag to the args argument.

If the user now want her data to be compressed by using the following command

build( ".", args = "--resave-data" )

both the --no-resave-data and --resave-data option are provided as arguments to the call of R CMD build.

This causes the argument provided by the user to be overwritten and renders the build function unable to compress the data.

check() and build() remove non-empty inst/rmarkdown directories

Hello,

My apologies if I've diagnosed this incorrectly. I have a package called socviz that supports my Data Visualization book. It's available here: http://github.com/kjhealy/socviz. Some users started reporting that an Rmarkdown template that's included in the package was not showing up in R Studio's menu of available templates. The template can be found in the usual place in the package: inst/rmarkdown/templates/ in a directory called dataviz_notes, inside of which is a template.yaml file and a skeleton directory containing skeleton.Rmd.

It seems that devtools::check(), devtools::build() and thus also devtools::install_github() are not copying the contents of my inst/rmarkdown when installing the library. Instead, during the check() or build() steps, the directory is reported as empty and removed before the install() stage. Here's some sample output from devtools::check():

> check()
Updating socviz documentation
Writing NAMESPACE
Loading socviz
Writing NAMESPACE
── Building ────────────────────────────────────────────────────────── socviz ──
Setting env vars:
● CFLAGS    : -Wall -pedantic -fdiagnostics-color=always
● CXXFLAGS  : -Wall -pedantic -fdiagnostics-color=always
● CXX11FLAGS: -Wall -pedantic -fdiagnostics-color=always
────────────────────────────────────────────────────────────────────────────────
βœ”  checking for file β€˜/Users/kjhealy/Source/socviz/DESCRIPTION’ ...
─  preparing β€˜socviz’: (374ms)
βœ”  checking DESCRIPTION meta-information
─  checking for LF line-endings in source and make files and shell scripts
─  checking for empty or unneeded directories
   Removed empty directory β€˜socviz/inst/rmarkdown’
─  looking to see if a β€˜data/datalist’ file should be added
─  building β€˜socviz_0.7.9000.tar.gz’

[etc]

And devtools::build() is the same:

βœ”  checking for file β€˜/Users/kjhealy/Source/socviz/DESCRIPTION’ ...
─  preparing β€˜socviz’: (412ms)
βœ”  checking DESCRIPTION meta-information
─  checking for LF line-endings in source and make files and shell scripts
─  checking for empty or unneeded directories
   Removed empty directory β€˜socviz/inst/rmarkdown’
─  looking to see if a β€˜data/datalist’ file should be added
─  building β€˜socviz_0.7.9000.tar.gz’
   
[1] "/Users/kjhealy/Source/socviz_0.7.9000.tar.gz"

If I put a placeholder file at the top level of the inst/rmarkdown directory, the rmarkdown directory will be copied (along with the placeholder file) but not any subdirectories. Putting placeholders in subdirectories that would otherwise contain directories does not result in them being preserved.

Installing the package locally and outside of devtools with R CMD BUILD and R CMD INSTALL results in the rmarkdown directory getting installed as expected, and the templates being available for R Studio users.

To reproduce, you can do, e.g.:

devtools::install_github("kjhealy/socviz")

and then compare what gets installed in the package's folder in your local R library with what should be installed given the contents of inst/ in the package source.

Session information:

─ Session info ───────────────────────────────────────────────────────────────
 setting  value                       
 version  R version 3.5.1 (2018-07-02)
 os       macOS  10.14.2              
 system   x86_64, darwin15.6.0        
 ui       X11                         
 language (EN)                        
 collate  en_US.UTF-8                 
 ctype    en_US.UTF-8                 
 tz       America/New_York            
 date     2019-01-02                  

─ Packages ───────────────────────────────────────────────────────────────────
 package     * version date       lib source        
 assertthat    0.2.0   2017-04-11 [1] CRAN (R 3.5.0)
 backports     1.1.2   2017-12-13 [1] CRAN (R 3.5.0)
 base64enc     0.1-3   2015-07-28 [1] CRAN (R 3.5.0)
 callr         3.0.0   2018-08-24 [1] CRAN (R 3.5.0)
 cli           1.0.1   2018-09-25 [1] CRAN (R 3.5.0)
 crayon        1.3.4   2017-09-16 [1] CRAN (R 3.5.0)
 debugme       1.1.0   2017-10-22 [1] CRAN (R 3.5.0)
 Defaults    * 1.1-1   2007-08-26 [1] CRAN (R 3.1.0)
 desc          1.2.0   2018-05-01 [1] CRAN (R 3.5.0)
 devtools    * 2.0.1   2018-10-26 [1] CRAN (R 3.5.1)
 digest        0.6.18  2018-10-10 [1] CRAN (R 3.5.0)
 fs            1.2.6   2018-08-23 [1] CRAN (R 3.5.0)
 glue          1.3.0   2018-07-17 [1] CRAN (R 3.5.0)
 kfigr       * 1.2     2015-07-15 [1] CRAN (R 3.5.0)
 kjhutils    * 0.3     2018-03-28 [1] local         
 knitr       * 1.21    2018-12-10 [1] CRAN (R 3.5.1)
 magrittr      1.5     2014-11-22 [1] CRAN (R 3.5.0)
 memoise       1.1.0   2017-04-21 [1] CRAN (R 3.5.0)
 pkgbuild      1.0.2   2018-10-16 [1] CRAN (R 3.5.0)
 pkgload       1.0.2   2018-10-29 [1] CRAN (R 3.5.0)
 prettyunits   1.0.2   2015-07-13 [1] CRAN (R 3.5.0)
 processx      3.2.0   2018-08-16 [1] CRAN (R 3.5.0)
 ps            1.2.1   2018-11-06 [1] CRAN (R 3.5.0)
 R6            2.3.0   2018-10-04 [1] CRAN (R 3.5.0)
 Rcpp          1.0.0   2018-11-07 [1] CRAN (R 3.5.0)
 remotes       2.0.2   2018-10-30 [1] CRAN (R 3.5.0)
 rlang         0.3.0.1 2018-10-25 [1] CRAN (R 3.5.0)
 rprojroot     1.3-2   2018-01-03 [1] CRAN (R 3.5.0)
 sessioninfo   1.1.1   2018-11-05 [1] CRAN (R 3.5.0)
 testthat    * 2.0.1   2018-10-13 [1] CRAN (R 3.5.0)
 usethis     * 1.4.0   2018-08-14 [1] CRAN (R 3.5.0)
 withr         2.1.2   2018-03-15 [1] CRAN (R 3.5.0)
 xfun          0.4     2018-10-23 [1] CRAN (R 3.5.0)

My desktop machine, by comparison, runs R 3.5.1 but with an earlier (1.13.6) version of devtools, and it works as expected:

Session info ------------------------------------------------------------------
 setting  value                       
 version  R version 3.5.1 (2018-07-02)
 system   x86_64, darwin15.6.0        
 ui       X11                         
 language (EN)                        
 collate  en_US.UTF-8                 
 tz       America/New_York            
 date     2019-01-02                  

Packages ----------------------------------------------------------------------
 package   * version date       source         
 base      * 3.5.1   2018-07-05 local          
 compiler    3.5.1   2018-07-05 local          
 datasets  * 3.5.1   2018-07-05 local          
 Defaults  * 1.1-1   2007-08-26 CRAN (R 3.1.0) 
 devtools  * 1.13.6  2018-06-27 CRAN (R 3.5.0) 
 digest      0.6.18  2018-10-10 cran (@0.6.18) 
 graphics  * 3.5.1   2018-07-05 local          
 grDevices * 3.5.1   2018-07-05 local          
 grid      * 3.5.1   2018-07-05 local          
 kfigr     * 1.2     2015-07-15 CRAN (R 3.5.0) 
 kjhutils  * 0.3     2018-03-28 local          
 knitr     * 1.20    2018-02-20 CRAN (R 3.5.0) 
 magrittr    1.5     2014-11-22 CRAN (R 3.5.0) 
 memoise     1.1.0   2017-04-21 CRAN (R 3.5.0) 
 methods   * 3.5.1   2018-07-05 local          
 R6          2.3.0   2018-10-04 cran (@2.3.0)  
 rlang       0.3.0.1 2018-10-25 cran (@0.3.0.1)
 stats     * 3.5.1   2018-07-05 local          
 testthat  * 2.0.1   2018-10-13 cran (@2.0.1)  
 tools       3.5.1   2018-07-05 local          
 utils     * 3.5.1   2018-07-05 local          
 withr       2.1.2   2018-03-15 CRAN (R 3.5.0) 

Thanks,

Kieran

Should we call R CMD build before R CMD INSTALL when building binary packages

According to WRE, that seems to be the proper way. So far I only noticed small differences when calling R CMD INSTALL --build on the folder directly:

  • The NeedsCompilation field is not added to DESCRIPTION
  • The Packaged field is not added to DESCRIPTION

But there might be other differences, since R CMD build does other things as well:

  • it runs the cleanup script, if there is one
  • converts line endings of source files
  • adds a datalist file, although only for non-lazy data, so not really relevant any more I guess
  • maybe more???

Should we run R CMD INSTALL --build on the result of R CMD build?

Also related: #34

Return success for `has_devel()`?

Possibly an issue for whattheyforgot, but I was confused by silence = success when running devtools::has_devel()for system prep (or perhaps it should be pkgbuild::check_build_tools() based on the usethis vignette here):
https://whattheyforgot.org/set-up-an-r-dev-environment.html#verify-system-prep
https://github.com/jennybc/what-they-forgot/blob/ec7696b21af2110e7f81262fd3cda8fd24c62e32/14_system-prep-for-build.Rmd#L47

Counterarguments:

  • It does say:

    If this function runs without error then congratulations, your R installation is properly set up!

  • I'm guessing there are good reasons for a successful check to be silent.

Possible alternative

  • Create a devel_sitrep() type function (probably in usethis) that is explicitly for returning messages about devel-readiness? (cc @jennybc β€” I browsed GH issues, but I might have missed something already present)

Automatically register C functions

If package has src/, doesn't use Rcpp, and has either no src/init.c or one previously created by pkgbuild:

  • Run tools::package_native_routine_registration_skeleton(".", character_only = FALSE)
  • Replace FIXME comment and with standard generated by comment
  • Save to src/init.c
  • Warn if namespace does not contain useDynLib(package, .registration = TRUE)

Building a tar.gz fails

❯ pkgbuild::build("~/works/dotenv_1.0.2.tar.gz", binary = TRUE)
Error: No root directory found in /Users/gaborcsardi/works/dotenv_1.0.2.tar.gz or its parent directories. Root criterion: contains a file `DESCRIPTION`

because

❯ pkgbuild:::pkg_has_src("~/works/dotenv_1.0.2.tar.gz")
Error: No root directory found in /Users/gaborcsardi/works/dotenv_1.0.2.tar.gz or its parent directories. Root criterion: contains a file `DESCRIPTION`

βœ” 75 MiB master*
❯ bt()

 1 pkgbuild::pkgbuild:::pkg_has_src ("~/works/dotenv_1.0.2.tar.gz")
 2 base::file.path (pkg_path(path), "src")
 3 pkgbuild::pkg_path (path)
 4 rprojroot::rprojroot::find_root ("DESCRIPTION", path)
 5 base::stop ("No root directory found in ", start_path, " or its parent dir …

 βœ– Error: No root directory found in /Users/gaborcsardi/works/dotenv_1.0.2.tar.gz or its parent directories. Root criterion: contains a file `DESCRIPTION

Why does `build_setup_source` delete `inst/doc`?

This behavior affects the package developer's source directory and is unavoidable when build(vignettes = TRUE). I am curious as to whether this step is necessary, or merely to avoid putting unnecessary things in the the resulting tarball.

If it is the latter, would you consider making (or allowing me via PR to make) it optional? The (longish) reason for the request follows below.


If inst/doc is forcibly deleted, this essentially precludes the possibility of including other (non-vignette) documentation in inst/doc via any other mechanism than vignettes/.install_extras. This particularly concerns a package I am developing (with @nevrome) which manages the Doxygen documentation for a developers C++ code.

Doxygen creates HTML documentation with subdirectories to which the entry point is a main file Doxygen/index.html. Unfortunately .install_extras does not preserve folder structure, so we would be forced to include the Doxygen doc via a non-standard location, e.g., inst/Doxygen.

This is perhaps merely an aesthetic concern, except we would also like to provide an entry point to the Doxygen documentation via an R vignette. This can easily be achieved from the Rmd file with the HTML "redirect"

<meta http-equiv="refresh" content="0; URL=path/to/Doxygen/index.html">

However, R forbids any redirects to files stored anywhere other than within inst/doc. Given the ubiquitous usage of devtools/pkgbuild by our intended developer base, I was curious as to whether there is a way around the deletion of inst/doc.

Suboptimal display of R CMD

pkgbuild:

Running command /Library/Frameworks/R.framework/Resources/bin/R 
Arguments:
CMD
build
/Users/hadley/Documents/devtools/devtools
--no-resave-data
--no-manual

CRAN devtools:

'/Library/Frameworks/R.framework/Resources/bin/R' --no-site-file --no-environ  \
  --no-save --no-restore --quiet CMD build  \
  '/Users/hadley/Documents/devtools/devtools' --no-resave-data --no-manual 

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.