[R-pkg-devel] Extending/adding to an R6 class from another package: qns

[Hong Ooi via R-package-devel]

--- Begin Message ---
I'm writing a family of packages for talking to Azure (Microsoft's cloud 
service) from R. The basic architecture is

AzureRMR: the "base" package, provides a number of R6 classes
AzureVM: a "child" package that extends classes from AzureRMR with extra 
functionality related to virtual machines
AzureStor: another child package that extends classes from AzureRMR, this time 
for storage accounts
Etc.

For example, AzureRMR defines a class called "az_resource_group" that 
represents an Azure resource group. Within this class, I have convenience 
functions to manage individual Azure resources: 
az_resource_group$get_resource(), az_resource_group$create_resource(), etc. One 
benefit of this approach is that method chaining works: I can do something like

   az_subscription("xxx")$get_resource_group("yyy")$get_resource("zzz").

In my child packages, I then define further classes and methods for dealing 
with specific services. For consistency, I also add convenience functions to 
the base AzureRMR::az_resource_group class to work with these new classes. For 
example, AzureVM defines a new class az_vm_template, and also adds a $get_vm() 
method to AzureRMR::az_resource_group.

Running devtools::check() however brings up a note and warning for the child 
packages. For example, with AzureVM:

* checking R code for possible problems ... NOTE
File 'AzureVM/R/add_methods.R':
  .onLoad calls:
message("Creating resource group '", resource_group, "'")

Package startup functions should use 'packageStartupMessage' to  generate 
messages.
See section 'Good practice' in '?.onAttach'.

. . .

* checking for code/documentation mismatches ... WARNING
Functions or methods with usage in documentation object 'get_vm' but not in 
code:
  get_vm get_vm_cluster list_vms


The reason for the note is because modifying R6 classes from another package 
has to be done at runtime, ie, in the .onLoad function. The message() call 
referred to is inside one of the new methods that I define for an AzureRMR 
class, hence it never actually appears at package startup. I assume it's okay 
to ignore this note?

The reason for the warning is because writing documentation for R6 methods is 
rather awkward, even/especially with Roxygen. This goes doubly so when the 
method in question is for a class from a different package. What I've done is 
to write a Roxygen block for the method as if it was a standalone function; for 
example, the documentation for az_resource_group$get_vm() is like this:

#' Get existing virtual machine(s)
#'
#' Method for the [AzureRMR::az_subscription] and [AzureRMR::az_resource_group] 
classes.
#'
#' @rdname get_vm
#' @name get_vm
#' @usage
#' get_vm(name)
#' get_vm(name, resource_group = name)
#'
#' @param name The name of the VM or cluster.
#' @param resource_group For the `az_subscription` method, the resource group 
in which `get_vm()` will look for the VM. Defaults to the VM name.
#'
#' @details
#' ...
NULL

This way, typing ?get_vm will bring up the relevant page, which seems to me to 
be the best compromise in terms of the end-user experience. Is this an 
acceptable way of doing the documentation for CRAN?

Hong

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

Re: [R-pkg-devel] Extending/adding to an R6 class from another package: qns

[Hong Ooi via R-package-devel]

--- Begin Message ---
I do use subclassing as you suggest. In my base package I have an az_resource 
class that represents any generic Azure resource. Eg in the VM package, I 
extend it to obtain az_vm_resource; in the storage package I extend it to 
obtain az_storage; and so on. In addition to simple subclassing, I also define 
more complex classes that combine resources of different types.

However, Azure also has a hierarchical structure where a subscription can 
contain multiple resource groups, each of which can contain multiple resources. 
So I have a resource_group class that includes functions to manage resources. 
It's this class that I'm adding methods to at runtime, so that you can work 
with az_vm_resource objects the same way that you work with az_resource objects.

Given that I'm using R6 (for its persistent state, since I'm tracking Azure 
resources), and given that I'm writing multiple packages, I don't really see 
any way around "monkey-patching" classes on load. Azure has approximately 1e6 
services on offer, and I don't want to support them via one monster package (in 
principle).

You can see the work-in-progress on the CloudyR repo if you like:
https://github.com/cloudyr/AzureRMR
https://github.com/cloudyr/AzureVM
https://github.com/cloudyr/AzureStor
https://github.com/cloudyr/AzureContainers

In any case, I've realised I can work around the note about startup messages by 
simply hiving off all the xxx$set() calls to a secondary function, rather than 
having them directly in .onLoad().


-Original Message-
From: Hadley Wickham  
Sent: Saturday, 20 October, 2018 2:42 AM
To: Hong Ooi 
Cc: R Package Development 
Subject: Re: [R-pkg-devel] Extending/adding to an R6 class from another 
package: qns


I think monkey-patching classes on load is an extremely bad idea. You
would be better off subclassing, or if the classes are so closely
inter-related, you should put them in a single package. Or re-design
your interface to use the pipe instead of method chaining so this
isn't a problem (brief discussion at
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fadv-r.hadley.nz%2Foo-tradeoffs.html%23tradeoffs-pipe&data=02%7C01%7Chongooi%40microsoft.com%7C444ca3edfdc6470f026208d635d97c48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636755605574903433&sdata=MQqYwnd7hWSEiEUeIFHUwzyo1SQ8R85Aq%2FpdqNW8ppg%3D&reserved=0)

> The reason for the warning is because writing documentation for R6 methods is 
> rather awkward, even/especially with Roxygen. This goes doubly so when the 
> method in question is for a class from a different package. What I've done is 
> to write a Roxygen block for the method as if it was a standalone function; 
> for example, the documentation for az_resource_group$get_vm() is like this:
>
> #' Get existing virtual machine(s)
> #'
> #' Method for the [AzureRMR::az_subscription] and 
> [AzureRMR::az_resource_group] classes.
> #'
> #' @rdname get_vm
> #' @name get_vm
> #' @usage
> #' get_vm(name)
> #' get_vm(name, resource_group = name)
> #'
> #' @param name The name of the VM or cluster.
> #' @param resource_group For the `az_subscription` method, the resource group 
> in which `get_vm()` will look for the VM. Defaults to the VM name.
> #'
> #' @details
> #' ...
> NULL
>
> This way, typing ?get_vm will bring up the relevant page, which seems to me 
> to be the best compromise in terms of the end-user experience. Is this an 
> acceptable way of doing the documentation for CRAN?

I think the usage should be consistent with how people actually call
the function, i.e. x$get_vm(name). I'm not sure if R CMD check will
like this, but I suspect it will silence the warning.

Hadley

-- 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhadley.nz&data=02%7C01%7Chongooi%40microsoft.com%7C444ca3edfdc6470f026208d635d97c48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636755605574903433&sdata=sNTNDb%2BcxGHWvTkrhztq0%2F%2B6nqg97loNaU813Z5UN6s%3D&reserved=0
--- End Message ---
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] SystemRequirements: Berkeley DB STL

[Hong Ooi via R-package-devel]

--- Begin Message ---
This looks like a similar situation to the C++ Boost headers, which are 
packaged up for easy R consumption in the boost package. You could try doing 
that with BerkeleyDB.

There's another issue though: looking at your FAQ page, you seem to rely on a 
bunch of tools written by UCSC. These tools aren't available for Windows, or at 
least I didn't see a download link. What are Windows users supposed to do?


-Original Message-
From: R-package-devel  On Behalf Of Toby 
Hocking
Sent: Wednesday, 24 October, 2018 5:03 AM
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] SystemRequirements: Berkeley DB STL

I would like to put the 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftdhock%2FPeakSegDisk&data=02%7C01%7Chongooi%40microsoft.com%7C8a2dca6e52e844d5f38808d6392ba1c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636759256910869612&sdata=bxglS4I%2BlPieYCAjiZHIAvnkOLqCIwxj%2BPocGrfRR2Q%3D&reserved=0
 package on
CRAN. This package needs Berkeley DB C++ Standard Template Library. What do
I need to do to get this package (with compiled mac/windows binaries) on
CRAN?

This C++ library is relatively easy to install
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftdhock%2FPeakSegPipeline%2Fwiki%2FFAQ%23installing-berkeleydb-stl&data=02%7C01%7Chongooi%40microsoft.com%7C8a2dca6e52e844d5f38808d6392ba1c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636759256910869612&sdata=%2FGQgkzrA7bveVJkRGcfr4swCsZ5EoQUzqRcW%2BGR8lS0%3D&reserved=0
but probably too big (tar.gz source code is 43MB) to include in the R
package, so I have indicated this external library dependency in the
SystemRequirements field of DESCRIPTION. I have also put PKG_LIBS=-ldb_stl
in my src/Makevars. Is that OK?

My Linux travis builds pass CRAN checks just fine
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis-ci.org%2Ftdhock%2FPeakSegDisk%2Fjobs%2F442813478&data=02%7C01%7Chongooi%40microsoft.com%7C8a2dca6e52e844d5f38808d6392ba1c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636759256910869612&sdata=RGv3KjWuWcp7mR2JVBZzFj7mQErYHceC2cweRwWD93E%3D&reserved=0
 because I have
installed the libdb5.1-stl-dev package which provides -ldb_stl.

Usually I check my packages on win-builder prior to CRAN submission. When I
check PeakSegDisk on win-builder, I get a linker error (db_stl not found)
because presumbly it is not installed on the win-builder machine. So
presumably my package would not pass checks on CRAN.

I have emailed Uwe Ligges to ask to install BerkeleyDB STL on win-builder
but I have got no response. Is there anybody else I should ask?

Is there anything else I should do?

FYI I believe that I have done my homework. From a search of
"systemrequirements" on r-package-devel I saw that there are several
related threads, for example a message on Feb 4 from Dirk who explains how
to use PKG_LIBS. However I did not see any specific explanation of how to
get a package with dependent compiled code on CRAN. Maybe the officially
accepted method should be added to Writing R Extensions or CRAN Repository
policies?

Thanks in advance for any help/advice you can provide.
Toby Dylan Hocking

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7C8a2dca6e52e844d5f38808d6392ba1c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636759256910869612&sdata=JHyirFiiFY9zonR9p2CgeQh2EuP3YBsi%2FZLG2NFv%2FDA%3D&reserved=0

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

Re: [R-pkg-devel] Fwd: [CRAN-pretest-archived] CRAN submission vioplot 0.3.0

[Hong Ooi via R-package-devel]

--- Begin Message ---
Just a few comments:

- Given vioplot 0.2 is 12 years old, I wouldn't be TOO concerned with backward 
compatibility. I wouldn't ignore it either, but if I had to choose, I'd go for 
modern idioms over ensuring that everything works exactly the same.

- You don't need to keep HTML versions of the vignettes in the repo. They'll be 
built automatically from the Rmd files when you run 
install.packages("vioplot"). Also, if size is an issue, you can set output: 
rmarkdown::html_vignette instead of rmarkdown::html_document which reduces the 
output size considerably.

- Using attach() to evaluate a formula in the context of a data frame should 
never be necessary; use model.frame(*, data=df) or eval(*, envir=df). That 
said, I didn't see any uses of attach in the repo, so presumably you've already 
fixed this.

- BSD is a very permissive license. While I'm not a lawyer, I don't think there 
would be any conflicts if you changed it to, say, the MIT license which is also 
very permissive.

-Original Message-
From: R-package-devel  On Behalf Of Tom 
Kelly
Sent: Wednesday, 26 December, 2018 7:01 PM
To: cran-submissi...@r-project.org; r-package-devel@r-project.org
Subject: [R-pkg-devel] Fwd: [CRAN-pretest-archived] CRAN submission vioplot 
0.3.0

Dear CRAN maintainers and R package developers,

I am still interested in submitting this update to the "vioplot" package. I 
would like to revisit the idea to update this package on CRAN. I think the 
changes that I've made here would be useful to a significant number of R users.

I am submitting to take over as maintainer as this package has been orphaned 
for years. I will of course take measures to attribute the original author and 
preserve the original LICENSE.

This is a major update with many additional features. This includes fine 
control over plotting parameters and formula inputs with documentation on these 
parameters. I've added tests and vignettes showing that these work.
However, it does not pass automated checks such as the LICENSE since some 
aspects of the original package are very outdated (the additional NOTEs from 
the CRAN checks were due to the outdated LICENSE and not being the current 
maintainer). Thus a manual review would be required. Otherwise, I have taken 
every measure I think is possible to reduce the number of errors from automated 
checks and ensure backwards compatibility. These additional features can be 
pushed to the repo without disrupting the behaviour of any existing scripts or 
packages calling this function.

I realise that the files may since been removed and I would need to resubmit if 
it is possible. These can be found at the following GitHub repo:

https://github.com/TomKellyGenetics/vioplot

Kind regards,

Tom Kelly

-- Forwarded message -
From: Tom Kelly 
Date: Sun, Feb 25, 2018 at 10:33 AM
Subject: Re: [CRAN-pretest-archived] CRAN submission vioplot 0.3.0
To: 
Cc: Tom Kelly 


Dear CRAN team,

I have documented the NOTE issues in a cran-comments.md file. I think some of 
these are unavoidable as stated in this file. In particular, some issues with 
automated checks may arise due to legacy code and meta-data for compatibility 
with vioplot 0.2 (last updated in 2005). Please notice that many of the checks 
failed by the original package vioplot 0.2 have been resolved with this 
release. In addition, this supports range of added features and input methods 
consistent with similar plotting functions while preserving 
backwards-compatibility.

Due to the proposal to take over as maintainer of an orphaned package, I 
request that this submission be reviewed manually. Sorry for the inconvenience, 
I will do my best to resolve any further issues that should arise.

Kind Regards,

Tom Kelly


On Sun, Feb 25, 2018 at 12:34 AM,  wrote:

> Dear maintainer,
>
> package vioplot_0.3.0.tar.gz does not pass the incoming checks 
> automatically, please see the pre-test at:
> <
> https://win-builder.r-project.org/incoming_pretest/180224_163015_viopl
> ot_030/00check.log
> >
> Status: 5 NOTEs
>
> Current CRAN status: NOTE: 12
> See: 
> 
>
> Please fix all problems and resubmit a fixed version via the webform.
> If you are not sure how to fix the problems shown, please ask for help 
> on the R-package-devel mailing list:
> 
> If you are fairly certain the rejection is a false positive, please 
> reply-all to this message and explain.
>
> More details are given in the directory:
> <
> https://win-builder.r-project.org/incoming_pretest/180224_163015_viopl
> ot_030
> >
> The files will be removed after roughly 7 days.
>
> Strong rev. depends: parviol regplot
>
> Best regards,
> CRAN teams' auto-check service
>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CMD INSTALL succeeds while R CMD BUILD fails

[Hong Ooi via R-package-devel]

--- Begin Message ---
It looks like the ".rdata" in your package name is confusing R CMD BUILD into 
thinking there is a .rdata file involved. Consider renaming it to "bcmaps.data" 
or something similar.


-Original Message-
From: R-package-devel  On Behalf Of Sam 
Albers
Sent: Friday, 11 January, 2019 2:07 PM
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] R CMD INSTALL succeeds while R CMD BUILD fails

Hello all,

I am experiencing some issues with building a package that we are hosting on 
GitHub. The package itself is quite large.  It is a data package with a bunch 
of spatial files stored as .rds files.

The repo is located here: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbcgov%2Fbcmaps.rdata&data=02%7C01%7Chongooi%40microsoft.com%7C6ac8c309c7b84a8de4d208d677fef252%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636828334223679364&sdata=GosuFnTADrpxapDMNQSMxKoI9B4aPtIw7LwPwoCmYxU%3D&reserved=0

If we clone that package to local machine via:
git clone 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbcgov%2Fbcmaps.rdata&data=02%7C01%7Chongooi%40microsoft.com%7C6ac8c309c7b84a8de4d208d677fef252%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636828334223679364&sdata=GosuFnTADrpxapDMNQSMxKoI9B4aPtIw7LwPwoCmYxU%3D&reserved=0

The first oddity is that the package installs successfully using this:

$ R CMD INSTALL "./bcmaps.rdata"

But fails when I try to build the package:

$ R CMD BUILD "./bcmaps.rdata"
* checking for file './bcmaps.rdata/DESCRIPTION' ... OK
* preparing 'bcmaps.rdata':
* checking DESCRIPTION meta-information ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* looking to see if a 'data/datalist' file should be added Warning in 
gzfile(file, "rb") :
  cannot open compressed file 'bcmaps.rdata', probable reason 'Permission 
denied'
Error in gzfile(file, "rb") : cannot open the connection Execution halted


The second oddity is that if I remove the . from the Package name in the 
DESCRIPTION file, the build proceeds smoothly:

$ R CMD build "./bcmaps.rdata"
* checking for file './bcmaps.rdata/DESCRIPTION' ... OK
* preparing 'bcmapsrdata':
* checking DESCRIPTION meta-information ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* looking to see if a 'data/datalist' file should be added
* building 'bcmapsrdata_0.2.0.tar.gz'

I am assuming that R CMD install builds the package internally so I find it 
confusing that I am not able to build it myself. Similarly confusing is the 
lack of a . in the package name indicative of anything?

Does anyone have any idea what's going on here? Am I missing something obvious?

Thanks in advance,

Sam

__
R-package-devel@r-project.org mailing list
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7C6ac8c309c7b84a8de4d208d677fef252%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636828334223679364&sdata=0r%2FFfRH6eYqRPLAAFLprWAttPip02VKV0GIqBOtVhI8%3D&reserved=0

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

Re: [R-pkg-devel] vignette problems: invisible

[Hong Ooi via R-package-devel]

--- Begin Message ---
The various devtools::install_* functions don't install vignettes by default; 
to do so, add the build_vignettes=TRUE argument.

-Original Message-
From: R-package-devel  On Behalf Of 
Troels Ring
Sent: Friday, 1 February, 2019 10:15 PM
To: package-develop 
Subject: [R-pkg-devel] vignette problems: invisible

Dear friends - I'm closing in on finalizing the package and its current version 
is on github/troelsring/ABCharge and it passes ctrl shift E without errors and 
now also has a vignette. I can see the vignette OK in its directory but issuing 
after installing from github by devtools, it cannot be called from 
help(package="ABCharge") or : vignette(package="ABCharge").

 

> devtools::install_github("troelsring/ABCharge",force=TRUE)

Downloading GitHub repo troelsring/ABCharge@master

  

  

   checking for file
'C:\Users\Troels\AppData\Local\Temp\RtmpSa60vS\remotes2b4452b72409\troelsrin
g-ABCharge-4b62da6/DESCRIPTION' ...

  

   checking for file
'C:\Users\Troels\AppData\Local\Temp\RtmpSa60vS\remotes2b4452b72409\troelsrin
g-ABCharge-4b62da6/DESCRIPTION' ... 

  

v  checking for file
'C:\Users\Troels\AppData\Local\Temp\RtmpSa60vS\remotes2b4452b72409\troelsrin
g-ABCharge-4b62da6/DESCRIPTION'

 

  

-  preparing 'ABCharge':

   checking DESCRIPTION meta-information ...

  

   checking DESCRIPTION meta-information ... 

  

v  checking DESCRIPTION meta-information

  

  

-  checking for LF line-endings in source and make files and shell scripts

 

   

  

-  checking for empty or unneeded directories

 



  

-  looking to see if a 'data/datalist' file should be added

 

   

  

-  building 'ABCharge_0.1.0.tar.gz'

   

 

Installing package into 'C:/Users/Troels/Documents/R/win-library/3.5'

(as 'lib' is unspecified)

* installing *source* package 'ABCharge' ...

** R

** data

** byte-compile and prepare package for lazy loading

** help

*** installing help indices

  converting help for package 'ABCharge'

finding HTML links ... done

BCharge html  

Baeza   html  

Bspecif html  

CMB html  

CO2specif   html  

GET_CH  html  

K3  html  

Kc  html  

Pittsburgh  html  

Schell  html  

Tessman html  

bromhtml  

getIhtml  

getfs   html  

kw  html  

malate  html  

pH_general  html  

** building package indices

** installing vignettes

** testing if installed package can be loaded

*** arch - i386

*** arch - x64

* DONE (ABCharge)

In R CMD INSTALL

> help(package=ABCharge)

starting httpd help server ... done

> vignette(package="ABCharge")

no vignettes found

 

I believe I have been through the list in Hadley's "Vignettes: long-form 
documentation" without finding the explanation.

 

Wonder what error I did make:

All best wishes

Troels Ring, MD


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7Ce265aaf98a98483539d308d6883681a5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636846165026041774&sdata=HscUwUke5%2Bwd26xQY0FmwdE7zeOy%2FAuhmNYQfTvsvS4%3D&reserved=0

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

Re: [R-pkg-devel] active bindings in package namespace

[Hong Ooi via R-package-devel]

--- Begin Message ---
Don't want to turn this into a pile-on, but I also think this isn't a very good 
idea. As I understand it, accessing the symbol "foo" will pull the latest 
version of foo from the remote site. This has consequences for reproducibility, 
because now your code could be exactly the same, and your local environment 
exactly the same, and yet running the code at different times can yield 
different results because the remote data has been updated.


-Original Message-
From: R-package-devel  On Behalf Of Jack 
Wasey
Sent: Sunday, 24 March 2019 9:57 AM
To: Kirill Müller ; R Development 

Subject: Re: [R-pkg-devel] active bindings in package namespace

Thanks both, this is helpful advice.

On 3/23/19 5:14 PM, Kirill Müller wrote:
> Dear Jack
> 
> 
> This doesn't answer your question, but I would advise against this design.
> 
> - Users do not expect side effects (such as network access) from accessing a 
> symbol.
> 
> - A function gives you much more flexibility to change the interface 
> later on. (Arguments for fetching the data, tokens for API access, 
> ...)
> 
> - You already encountered a few quirks that make this an "interesting" 
> problem.
> 
> A function call only needs a pair of parentheses.
> 
> 
> Best regards
> 
> Kirill
> 
> 
> On 23.03.19 16:50, Jack O. Wasey wrote:
>> Dear all,
>>
>> I am developing a package which is a front for various online data (icd.data 
>> https://github.com/jackwasey/icd.data/ ). The current CRAN version just has 
>> lazy-loaded data, but now the package encompasses far more current and 
>> historic ICD codes from different countries, these can't be included in the 
>> CRAN package even with maximal compression.
>>
>> Other authors have solved this using functions to get the data, with or 
>> without a local cache of the retrieved data. No CRAN or other packages I 
>> have found after extensive searching use the attractive active binding 
>> feature of R.
>>
>> The goal is simple: for the user to refer to the data by its symbol, e.g., 
>> 'icd10fr2019', or 'icd.data::icd10fr2019', and it will be downloaded and 
>> parsed transparently (if the user has already granted permission, or after 
>> prompt if they haven't).
>>
>> The bindings are set using commands alongside the function definitions in 
>> R/*.R .E.g.
>>
>> makeActiveBinding("icd10cm_latest", .icd10cm_latest_binding, 
>> environment()) lockBinding("icd10cm_latest", environment())
>>
>> For non-interactive use, CI and CRAN tests, no data should be downloaded, 
>> and no cache directory set up without user consent. For interactive use, I 
>> ask permission to create a local data cache before downloading data.
>>
>> This works fine... until R CMD check. The following steps seems to 'get' or 
>> 'source' everything from the package namespace, which results in triggering 
>> the active bindings, and this fails if I am unable to get consent to 
>> download data, and want to 'stop' on this error condition.
>>  - checking dependencies in R code
>>  - checking S3 generic/method consistency
>>  - checking foreign function calls
>>  - checking R code for possible problems
>>
>> Debugging CI-specific binding bugs is a nightmare because these occur in 
>> different R sessions initiated by R CMD check.
>>
>> There may be legitimate reasons to evaluate everything in the 
>> namespace, but I've no idea what they are. Incidentally, Rstudio also 
>> does 'mget' on the whole package namespace and triggers bindings 
>> during autocomplete. https://github.com/rstudio/rstudio/issues/4414
>>
>> Is this something I should raise as an issue with R? Or does anyone have any 
>> idea of a sensible approach to this. Currently I have a set of workarounds, 
>> but this complicates the code, and has taken an awful lot of time. Does 
>> anyone know of any CRAN package which has active bindings in the package 
>> namespace?
>>
>> Any ideas appreciated.
>>
>> Jack Wasey
>>
>> __
>> 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
--- End Message ---
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN student assistants

[Hong Ooi via R-package-devel]

--- Begin Message ---
I had a similar experience with a couple of my package updates needing changes. 
The background is that I have a family of packages for talking to Microsoft's 
Azure cloud service from R, and my examples are all marked \dontrun because 
they need an Azure subscription to work. This had previously been cleared with 
Uwe Ligges, but I guess the other CRAN reviewers weren't aware of this.
 
In both cases, replying to the CRAN email and cc'ing Uwe resolved the issue 
quickly and without fuss.


-Original Message-
From: R-package-devel  On Behalf Of Mark 
van der Loo
Sent: Thursday, 16 May 2019 1:50 AM
To: Jennifer Bryan 
Cc: R Package Development 
Subject: Re: [R-pkg-devel] CRAN student assistants

For what it's worth,

I recently submitted a new package that was initially refused (with
comments) by CRAN. I updated number of them accordingly, but there were a few 
that with good reasons I could not change. I explained this in the comments 
when uploading a new version and it got accepted. So I don't see the problem.

(The case here was a use of \dontrun{}. I had to switch an example off because 
a warning was thrown which would upset R CMD check. But demonstrating the 
warning was exactly the point of the example.)

All this aside. I think it is extremely unethical to publish privately sent 
CRAN emails on GH, including personal details such as name and e-mail address 
of the sender without their explicit consent.


Best,
Mark





On Wed, May 15, 2019 at 4:44 PM Jennifer Bryan 
wrote:

> Hello,
>
> Since this has turned into a worldwide code review, I will briefly 
> address that, then reiterate the point of the original message.
>
> I am working on an initial release of a package. It reveals 
> information to a user, sometimes in a print method-y way, sometimes in 
> more of a verbose / debugging way that is under control of a 
> documented option, which defaults to "off" or "quiet". For now, I have 
> chosen to send all of this output through a single functions that, 
> yes, uses cat(). I went this direction for an initial release to keep 
> the package simple and accumulate some user experience. If the 
> "debugging mode" proves to be useful, I will rework it, possibly using 
> UI functionality that I believe our group might release in the future. 
> Rest assured, I understand cat() vs message() and the various 
> tradeoffs. I made mine and it is my impression that package maintainers have 
> this level of freedom.
>
> The real point is: the currenrt CRAN submission process is designed 
> for one-way communication and there's no guarantee of continuity of reviewer.
> If this type of implementation review is going to happen, it seems 
> that many aspects of the process would need to change, to make sure 
> these new standards are applied consistently to every submission and 
> that existing package are brought up to current standards.
>
> To clarify something for Joris, I am not aware of any special channel 
> of communication or influence between CRAN and the R Foundation (of 
> which I am also a member). I think this is an aspect of CRAN vs R 
> Foundation (vs R Core even) that is unclear to many. These entities 
> operate quite independently, except for the fact that specific people 
> belong to more than one. So RF members interact with CRAN the same way 
> as any other of member of the community.
>
> -- Jenny
>
> On Wed, May 15, 2019 at 6:43 AM Jim Hester 
> wrote:
>
> > Sorry first sentence should read
> >
> > I agree that `message()` is ideally preferred, precisely because of 
> > the reasons Martin stated, it is easily controlled by the user.
> >
> > On Wed, May 15, 2019 at 9:41 AM Jim Hester 
> > 
> > wrote:
> > >
> > > I agree that `message()` is in an ideally preferred, precisely 
> > > because of the reasons Martin stated, it is easily controlled by the user.
> > >
> > > Unfortunately, in the real world, the windows R gui console and 
> > > RStudio (which copied behavior) color messages, and anything on 
> > > stderr in fact, in red, which confuses most users who are trained 
> > > to treat messages in red as errors.
> > >
> > > This also makes using colored output (where available) more 
> > > challenging when using `message()`.  You either have to accept the 
> > > text as red, or unconditionally change the text color to black or 
> > > similar, which can then be unreadable if the user is using a dark 
> > > color theme.
> > >
> > > Jenny is an experienced package developer. She knew this tradeoff 
> > > and the use of `cat()` in gargle was deliberate choice in an 
> > > imperfect world. She did not make this decision out of ignorance 
> > > of a better way.
> > >
> > > However there is no way for Jenny or any other package developers 
> > > to have a dialog during a CRAN submission, the communication is 
> > > only in one direction, if she resubmits explaining her rationale 
> > > for the choice she may not even have the same reviewer the next time.
> > >
> > > B

Re: [R-pkg-devel] CRAN student assistants

[Hong Ooi via R-package-devel]

--- Begin Message ---
I don’t think they check _every_ help page for examples. My assumption would be 
that if the main functionality of the package is covered, then functions that 
are clearly ancillary, or whose usage is obvious, get a pass.

Another reason for cloud-related packages to mark things as \dontrun (as 
opposed to \donttest) would be if they deploy resources that have an associated 
cost. You probably don’t want to be charged 50 bucks, or whatever, for 
deploying a compute cluster just by running example().

From: Jennifer Bryan 
Sent: Friday, 17 May 2019 3:10 AM
To: Hong Ooi 
Cc: R Package Development 
Subject: Re: [R-pkg-devel] CRAN student assistants

Thanks for the excellent comparable package, Hong.

Today's rejection of gargle instructs me to use \donttest{} instead of 
\dontrun{}. Most of the affected functions create, load, and/or refresh service 
account tokens and OAuth2 credentials. I see that \dontrun{} is used in 
AzureAuth, which does seem more appropriate and is what I did. My impression is 
that \donttest{} code is still run under some circumstances. Perhaps this is 
another good topic for discussion, now that we've worked through cat() vs 
message().

It seems like you've also got a few functions without examples at all (e.g., 
format_auth_header(), AzureR_dir()). How does this get through CRAN review? 
When is that OK and when is it not?

I would simply like to understand the standards, so that I can impose them on 
myself and go through fewer submissions. Maybe we could even automate some of 
those checks. That would reduce workload all around.

I've taken your advice to reply via email with full explanation and cc others 
at CRAN. Maybe this will also lead to speedy resolution with no fuss.

-- Jenny

On Wed, May 15, 2019 at 2:18 PM Hong Ooi 
mailto:hong...@microsoft.com>> wrote:
I had a similar experience with a couple of my package updates needing changes. 
The background is that I have a family of packages for talking to Microsoft's 
Azure cloud service from R, and my examples are all marked \dontrun because 
they need an Azure subscription to work. This had previously been cleared with 
Uwe Ligges, but I guess the other CRAN reviewers weren't aware of this.

In both cases, replying to the CRAN email and cc'ing Uwe resolved the issue 
quickly and without fuss.


-Original Message-
From: R-package-devel 
mailto:r-package-devel-boun...@r-project.org>>
 On Behalf Of Mark van der Loo
Sent: Thursday, 16 May 2019 1:50 AM
To: Jennifer Bryan mailto:jenny.f.br...@gmail.com>>
Cc: R Package Development 
mailto:r-package-devel@r-project.org>>
Subject: Re: [R-pkg-devel] CRAN student assistants

For what it's worth,

I recently submitted a new package that was initially refused (with
comments) by CRAN. I updated number of them accordingly, but there were a few 
that with good reasons I could not change. I explained this in the comments 
when uploading a new version and it got accepted. So I don't see the problem.

(The case here was a use of \dontrun{}. I had to switch an example off because 
a warning was thrown which would upset R CMD check. But demonstrating the 
warning was exactly the point of the example.)

All this aside. I think it is extremely unethical to publish privately sent 
CRAN emails on GH, including personal details such as name and e-mail address 
of the sender without their explicit consent.


Best,
Mark





On Wed, May 15, 2019 at 4:44 PM Jennifer Bryan 
mailto:jenny.f.br...@gmail.com>>
wrote:

> Hello,
>
> Since this has turned into a worldwide code review, I will briefly
> address that, then reiterate the point of the original message.
>
> I am working on an initial release of a package. It reveals
> information to a user, sometimes in a print method-y way, sometimes in
> more of a verbose / debugging way that is under control of a
> documented option, which defaults to "off" or "quiet". For now, I have
> chosen to send all of this output through a single functions that,
> yes, uses cat(). I went this direction for an initial release to keep
> the package simple and accumulate some user experience. If the
> "debugging mode" proves to be useful, I will rework it, possibly using
> UI functionality that I believe our group might release in the future.
> Rest assured, I understand cat() vs message() and the various
> tradeoffs. I made mine and it is my impression that package maintainers have 
> this level of freedom.
>
> The real point is: the currenrt CRAN submission process is designed
> for one-way communication and there's no guarantee of continuity of reviewer.
> If this type of implementation review is going to happen, it seems
> that many aspects of the process would need to change, to make sure
> these new standards are applied consistently to every submission and
> that existing package are brought up to current standards.
>
> To clarify something for Joris, I am not aware of any special channel
> of communication or influence between CRAN and th

Re: [R-pkg-devel] CRAN policies with regards to runnable examples

[Hong Ooi via R-package-devel]

Hm, up to now my AzureR packages haven't met with any issues, and they are 
basically API wrappers.

I did have one reviewer ask for runnable examples when I submitted one package, 
but replying and pointing out the issues you mention cleared things up. I did 
cc Uwe Ligges in the reply, who approved the other packages in the first place 
-- the other reviewer probably just wasn't aware that I'd cleared things with 
Uwe previously.


-Original Message-
From: R-package-devel  On Behalf Of Jim 
Hester
Sent: Wednesday, 2 October 2019 3:37 AM
To: R Package Development 
Subject: [R-pkg-devel] CRAN policies with regards to runnable examples

CRAN reviewers have somewhat recently been requesting that new submissions have 
runnable examples. This is in general a good recommendation, but the reviewers 
seem to apply this policy unconditionally, and there are certain classes of 
packages where this is either extremely cumbersome or impossible to do.

Two in particular are packages which wrap web APIs and packages containing 
shiny applications. Even the most robust APIs will inevitably have network 
failures, causing spurious failures on CRAN's machines, and often the APIs 
require credentials to access, which won't be available on the build machines. 
Shiny applications block the R process and require user interaction in a 
browser to function, they cannot really be run non-interactively.

In these cases it seems appropriate to put examples in a `\dontrun{}` or 
`\donttest{}` block, and this is what is suggested by writing R extensions. 
However CRAN reviewers have refused to accept packages taking this approach.

If these workarounds are not acceptable what _does_ CRAN want package authors 
to do in these cases?

Jim

__
R-package-devel@r-project.org mailing list
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7C1ac67369474848bf7cdc08d746960dd9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637055482613833043&sdata=quC7BH5vtm3I7dWq%2Fhi6FtN54DxrUzO0Z1K9TRc%2FE3c%3D&reserved=0

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

Re: [R-pkg-devel] R package which creates a directory in the user home dir

[Hong Ooi via R-package-devel]

Also, consider using the rappdirs package to write to a location that follows 
standard practice on each platform.


-Original Message-
From: R-package-devel  On Behalf Of 
Martin Maechler
Sent: Thursday, 17 October 2019 11:44 PM
To: Sigbert Klinke 
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R package which creates a directory in the user home 
dir

> Sigbert Klinke 
> on Thu, 17 Oct 2019 14:29:54 +0200 writes:

> Hi,
> I'am developing a package that circumvents the R package size limitation 
> for data sets. For this I store the data set in the internet (currently 
> GitHub) and download if it is requested.

> To avoid unnecessary downloads and internet connections I create a 
> directory in the users home directory to store the data there. However, 
> this violates the "CRAN Repository Policy" which says

> - Packages should not write in the user’s home filespace (including 
> clipboards), nor anywhere else on the file system apart from the R 
> session’s temporary directory (or during installation in the location 
> pointed to by TMPDIR: and such usage should be cleaned up).

> Do I have any chance to get the package to CRAN, if I submit it?

> Best Sigbert

> 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhu.berlin%2Fsk&data=02%7C01%7Chongooi%40microsoft.com%7Cb0df7ca628c34c80856d08d752ffd245%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637069131007127544&sdata=1AVL8mEcu40nIo5XsWpAMooftEGX8V4W5armhNaFsGM%3D&reserved=0
> 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhu.berlin%2Fmmstat3&data=02%7C01%7Chongooi%40microsoft.com%7Cb0df7ca628c34c80856d08d752ffd245%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637069131007127544&sdata=sUfd89zI27LMfqUps7Hfhv%2BCvreUX4ZQJhTW1%2FGkcaY%3D&reserved=0


I you *prompt* the user about writing, i.e., ask them explicitly if  
is fine and only if "yes", you write there, otherwise try to write to tempdir() 
 then your package is fine, otherwise it is not, i.e, "not okay" according to 
many, even if *not* on CRAN..

Best,
Martin

__
R-package-devel@r-project.org mailing list
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7Cb0df7ca628c34c80856d08d752ffd245%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637069131007127544&sdata=UwCk8xz15BVi1OCwKpyZ7usO4nYnT4KtCZm7bHEP9Kc%3D&reserved=0
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Checkpoint package failing CRAN checks

[Hong Ooi via R-package-devel]

Hi all,

I'm the new (as of 6 months ago) maintainer of checkpoint. If you're not 
familiar with it, checkpoint is a package to help with reproducible analysis: 
you give it a particular snapshot date from the MRAN site, and it installs the 
packages that your project depends on from that snapshot.

Just before the Christmas break, I got a message that it was failing CRAN 
checks. Specifically, building a vignette was causing a warning that a file was 
not found. I've made some changes, but the error persists.

This is the snippet of the log with the error. The full log can be found at 
https://win-builder.r-project.org/incoming_pretest/checkpoint_0.4.8_20200108_065428/Debian/00check.log


Error(s) in re-building vignettes:
  ...
--- re-building 'checkpoint.Rmd' using rmarkdown
* installing *source* package 'darts' ...
** using staged installation
** libs
gcc-9  -I"/home/hornik/tmp/R-d-gcc-9/include" -DNDEBUG   -I/usr/local/include 
-DUSE_TYPE_CHECKING_STRICT -D_FORTIFY_SOURCE=2  -fpic  -g -O2 -Wall -pedantic 
-mtune=native  -c darts.c -o darts.o
gcc-9 -shared -L/home/hornik/tmp/R-d-gcc-9/lib -Wl,-O1 -o darts.so darts.o 
-L/home/hornik/tmp/R-d-gcc-9/lib -lR
installing to 
/tmp/RtmpNSFOaW/working_dir/RtmpshQt0J/.checkpoint/2017-04-01/lib/x86_64-pc-linux-gnu/4.0.0/00LOCK-darts/00new/darts/libs
** R
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
** checking absolute paths in shared objects and dynamic libraries
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (darts)
Warning in file(con, "w") :
  cannot open file 
'/tmp/RtmpNSFOaW/working_dir/RtmpshQt0J/rmarkdown-str2e0253dd0590.html': No 
such file or directory
Error: processing vignette 'checkpoint.Rmd' failed with diagnostics:
cannot open the connection
--- failed re-building 'checkpoint.Rmd'


Would anyone be able to provide a clue as to what's going on? It seems to be 
working on Windows, but not on Debian.

The full package source is at 
https://github.com/RevolutionAnalytics/checkpoint. Thanks!

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

Re: [R-pkg-devel] [EXTERNAL] Re: Checkpoint package failing CRAN checks

[Hong Ooi via R-package-devel]

Good catch, Ivan! Fixing that seems to have done the trick. Thanks!

The question now is why checkpoint hasn't crashed and burned prior to this, but 
I'll leave that for another day


-Original Message-
From: Ivan Krylov  
Sent: Friday, 10 January 2020 8:18 PM
To: Hong Ooi via R-package-devel 
Cc: Hong Ooi 
Subject: [EXTERNAL] Re: [R-pkg-devel] Checkpoint package failing CRAN checks

I wonder why does vignettes/checkpoint.Rmd run the following:

> example_project <- tempdir()

Now example_project contains the path of per-session temporary
directory...

> dir.create(example_project, recursive = TRUE, showWarnings = FALSE)

...so there should be no need to create it...

> unlink(example_project, recursive = TRUE)

And deleting it is might be the cause of the problems: rmarkdown
probably uses the same temporary directory to store its own files.

Perhaps example_project should be something like tempfile(project)
instead of just tempdir()? Then dir.create() and unlink() calls start
making sense.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] [EXTERNAL] Re: finding "logo.jpg" [was: "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC]

[Hong Ooi via R-package-devel]

I echo this. Relying on something undocumented and platform-specific, like the 
location of a random installation file, is just asking for problems. Instead, 
make a small image of your own and distribute it with your package.

-Original Message-
From: R-package-devel  On Behalf Of Ben 
Bolker
Sent: Tuesday, 4 February 2020 7:16 AM
To: r-package-devel@r-project.org
Subject: [EXTERNAL] Re: [R-pkg-devel] finding "logo.jpg" [was: "try" 
malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC]


  Maybe include your own version of logo.jpg in inst/ ?

On 2020-02-03 2:30 p.m., Spencer Graves wrote:
>   Thanks to Iñaki Ucar for identifying a second error that explained
> why I still got an error after wrapping one in "try".
> 
> 
>   That still leaves a question of how to find a file like "logo.jpg"
> in a platform independant way.
> 
> 
>       The following had worked for several years and now broke on rhub
> "Ubuntu Linux 16.04 LTS, R-release, GCC" but not on several other
> computers I tried:
> 
> 
>         logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg", sep =
> .Platform$file.sep)
> 
> 
>   On that Ubuntu platform, "readJPEG(logo.jpg)" stopped with "Error
> in readJPEG(logo.jpg) : unable to open /usr/lib/R/doc/html/logo.jpg".
> 
> 
>   I replaced the above "paste" with the following:
> 
> 
> RdocDir <- dir(R.home(), pattern='^doc$', full.names = TRUE)
> RhtmlDir <- dir(RdocDir, pattern='^html$', full.names=TRUE)
> JPGs <- dir(RhtmlDir, pattern='.jpg$', full.names=TRUE)
> if(length(JPGs)>1){
>   logoJPG <- paste0(.Platform$file.sep, 'logo.jpg$')
>   logo.jpg <- grep(logoJPG, JPGs, value=TRUE)
>   if(length(logo.jpg)>1)logo.jpg <- logo.jpg[1]
>   if(length(logo.jpg)<1)logo.jpg <- JPGs[1]
> } else logo.jpg <- JPGs
> if(length(logo.jpg)<1){
>   cat('logo.jpg not found.\n')
>   print(R.home())
>   print(dir(RdocDir))
>   print(dir(RhtmlDir))
>   if(!fda::CRAN())stop('logo.jpg not found')
> } else {
> # length(logo.jpg)==1 so continue:
>   if(require(jpeg)){
> ##
> ## 1.  Shrink as required
> ##
>     Rlogo <- readJPEG(logo.jpg)
> 
> ...
> 
> 
>       This gave me no error message, which I believe means that either
> length(logo.jpg) == 1 or fda::CRAN() returns TRUE.  Sadly, I could not
> find the standard test file to see which of these is the case.
> 
> 
>   I should proceed to submit the current Ecfun package to CRAN. Then
> I might modify this test sequence to force an error, so I can see more
> what is happening.
> 
> 
>   Suggestions?
>   Thanks,
>   Spencer
> 
> 
> On 2020-02-03 03:06, Iñaki Ucar wrote:
>> On Mon, 3 Feb 2020 at 03:16, Spencer Graves
>>  wrote:
>>> Hello, All:
>>>
>>>
>>>     devtools::check_rhub failed to trap an error wrapped in "try",
>>> per the email below.  This came from running
>>> devtools::check_rhub(Ecfun_dir), where Ecfun_dir = the path to a copy of
>>> "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsbgraves237%2FEcfun&data=02%7C01%7Chongooi%40microsoft.com%7C757daa698b0a4830eaa908d7a8e5e496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637163577651198242&sdata=NW7oju2vYnhaaYnNnP8q%2F5yG1Vqusa21CMnTQtUwPAs%3D&reserved=0";.
>> That's improbable.
>>
>>>     This is the development version of Ecfun, which I want to submit
>>> to CRAN as soon as I can do so without offending the sensibilities of
>>> the overworked CRAN maintainers.
>>>
>>>
>>>     Suggestions?
>>>     Thanks,
>>>     Spencer Graves
>>>
>>>
>>>  Forwarded Message 
>>> Subject:    Ecfun 0.2-2: ERROR
>>> Date:   Sun, 02 Feb 2020 23:27:10 +
>>> From:   R-hub builder 
>>> To: spencer.gra...@effectivedefense.org
>>>
>> 
>>
 ## 2.9.  A more complicated example with elements to eval
 ##
 logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg",
>>> +   sep = .Platform$file.sep)
 if(require(jpeg)){
>>> +   Rlogo <- try(readJPEG(logo.jpg))
>>> +   if(!inherits(Rlogo, 'try-error')){
>>> + # argument list for a call to rasterImage or rasterImageAdj
>>> + RlogoLoc <- list(image=Rlogo,
>>> +   xleft.0 = c(NZ=176.5,CH=172,US=171,
>>> +   CN=177,RU= 9.5,UK= 8),
>>> +   xleft.1 = c(NZ=176.5,CH=  9,US=-73.5,
>>> +   CN=125,RU= 37, UK= 2),
>>> +   ybottom.0=c(NZ=-37,  CH=-34,US=-34,
>>> +   CN=-33,RU= 48, UK=47),
>>> +   ybottom.1=c(NZ=-37,  CH= 47,US= 46,
>>> +   CN= 32,RU=55.6,UK=55),
>>> +   xright=quote(xleft+xinch(0.6)),
>>> +   ytop = quote(ybottom+yinch(0.6)),
>>> +   angle.0 =0,
>>> +   angle.1 =c(NZ=0,CH=3*360,US=5*360,
>>> +  CN=2*360,RU=360,UK=360)
>>> + )
>>> +
>>> + RlogoInterp <- interpPairs(RlogoLoc,
>>> + .proportion=rep(c(0, -1), c(2, 4)) )
>>> + # check
>>> + ## Don't show:
>>> + stopifnot(
>>> + ## End(Don't show)
>>> + all.equal(names(RlogoInterp),
>>> +    c('image', 'xright', 'ytop', 'xleft', 'ybottom', 'angle'))
>>> +

[R-pkg-devel] R CMD build hanging for some but not all packages

[Hong Ooi via R-package-devel]

This is with R 3.6.2 on Windows 10 Pro 1909.

In the last couple of weeks, devtools::build() and devtools::check() have 
started hanging on some, but not all, of my packages. After some poking around, 
I discovered that it's actually R CMD build that is having problems, right 
after the "checking for file 'DESCRIPTION'" step.

A reproducible example can be found by cloning my AzureStor package: 
https://github.com/Azure/AzureStor If you run "R CMD build ." in the package 
directory, it should hang. This is a relatively simple package that doesn't 
require compilation, although it does import some commonly-used packages like 
httr, curl, jsonlite and xml2.

As far as I can tell, R on Ubuntu works fine. What's going on?

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

Re: [R-pkg-devel] R CMD build hanging for some but not all packages

[Hong Ooi via R-package-devel]

Actually, cancel that: it finished successfully, but took 3 minutes to prepare 
the package:

r$> devtools::build()
v  checking for file 'C:\Users\hongo\Documents\GitHub\AzureStor/DESCRIPTION'

-  preparing 'AzureStor': (3m 4s)
v  checking DESCRIPTION meta-information ...
-  installing the package to build vignettes
v  creating vignettes (6.5s)
-  checking for LF line-endings in source and make files and shell scripts 
(13.8s)  
-  checking for empty or unneeded directories
-  building 'AzureStor_3.1.0.9000.tar.gz'

This is really weird, I'm used to the package prep step taking 10 seconds at 
most.


-Original Message-
From: R-package-devel  On Behalf Of Hong 
Ooi via R-package-devel
Sent: Tuesday, 11 February 2020 3:50 AM
To: r-package-devel@r-project.org
Subject: [EXTERNAL] [R-pkg-devel] R CMD build hanging for some but not all 
packages

This is with R 3.6.2 on Windows 10 Pro 1909.

In the last couple of weeks, devtools::build() and devtools::check() have 
started hanging on some, but not all, of my packages. After some poking around, 
I discovered that it's actually R CMD build that is having problems, right 
after the "checking for file 'DESCRIPTION'" step.

A reproducible example can be found by cloning my AzureStor package: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2FAzureStor&data=02%7C01%7Chongooi%40microsoft.com%7Cae76a58d39b64b491a1008d7ae4955a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637169502304943506&sdata=RW3TQM2D%2F3X43oGhiywDyKd%2F4oo5hFkOoVwZTUe9cOw%3D&reserved=0
 If you run "R CMD build ." in the package directory, it should hang. This is a 
relatively simple package that doesn't require compilation, although it does 
import some commonly-used packages like httr, curl, jsonlite and xml2.

As far as I can tell, R on Ubuntu works fine. What's going on?

__
R-package-devel@r-project.org mailing list
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7Cae76a58d39b64b491a1008d7ae4955a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637169502304943506&sdata=DPyD6zGGcxq41irkaMfMLyjnmqSB96PiIxIh9N2p%2Ft4%3D&reserved=0

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

Re: [R-pkg-devel] [EXTERNAL] Re: R CMD build hanging for some but not all packages

[Hong Ooi via R-package-devel]

That was it; I had a big subdirectory full of stuff I was using to test the 
package. Removing it caused the build time to drop back to 15 seconds. Thanks!

-Original Message-
From: Gábor Csárdi  
Sent: Tuesday, 11 February 2020 3:58 AM
To: Hong Ooi 
Cc: r-package-devel@r-project.org
Subject: [EXTERNAL] Re: [R-pkg-devel] R CMD build hanging for some but not all 
packages

Maybe you have large, ignored files in the package directory? R first
creates a copy of the whole directory and only applies `.Rbuildignore`
after that.

Gabor

On Mon, Feb 10, 2020 at 4:54 PM Hong Ooi via R-package-devel
 wrote:
>
> Actually, cancel that: it finished successfully, but took 3 minutes to 
> prepare the package:
>
> r$> devtools::build()
> v  checking for file 'C:\Users\hongo\Documents\GitHub\AzureStor/DESCRIPTION'
> -  preparing 'AzureStor': (3m 4s)
> v  checking DESCRIPTION meta-information ...
> -  installing the package to build vignettes
> v  creating vignettes (6.5s)
> -  checking for LF line-endings in source and make files and shell scripts 
> (13.8s)
> -  checking for empty or unneeded directories
> -  building 'AzureStor_3.1.0.9000.tar.gz'
>
> This is really weird, I'm used to the package prep step taking 10 seconds at 
> most.
>
>
> -Original Message-
> From: R-package-devel  On Behalf Of 
> Hong Ooi via R-package-devel
> Sent: Tuesday, 11 February 2020 3:50 AM
> To: r-package-devel@r-project.org
> Subject: [EXTERNAL] [R-pkg-devel] R CMD build hanging for some but not all 
> packages
>
> This is with R 3.6.2 on Windows 10 Pro 1909.
>
> In the last couple of weeks, devtools::build() and devtools::check() have 
> started hanging on some, but not all, of my packages. After some poking 
> around, I discovered that it's actually R CMD build that is having problems, 
> right after the "checking for file 'DESCRIPTION'" step.
>
> A reproducible example can be found by cloning my AzureStor package: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2FAzureStor&data=02%7C01%7Chongooi%40microsoft.com%7C262a7710f7e945edc5fc08d7ae4a7076%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637169507045837081&sdata=jZnomGihKN%2F4ObGTn5B6GP%2FFtO9jtE1PiNcv%2F6sd6n0%3D&reserved=0
>  If you run "R CMD build ." in the package directory, it should hang. This is 
> a relatively simple package that doesn't require compilation, although it 
> does import some commonly-used packages like httr, curl, jsonlite and xml2.
>
> As far as I can tell, R on Ubuntu works fine. What's going on?
>
> __
> R-package-devel@r-project.org mailing list
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7C262a7710f7e945edc5fc08d7ae4a7076%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637169507045837081&sdata=n4ZJZ3hqj7lwFazyUeZ3ECcN8da%2BE%2F3tPTvevWAgPXU%3D&reserved=0
>
> __
> R-package-devel@r-project.org mailing list
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7C262a7710f7e945edc5fc08d7ae4a7076%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637169507045837081&sdata=n4ZJZ3hqj7lwFazyUeZ3ECcN8da%2BE%2F3tPTvevWAgPXU%3D&reserved=0
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [EXTERNAL] Re: R CMD build hanging for some but not all packages

[Hong Ooi via R-package-devel]

They are scanned probably because R CMD build does something like cp * to copy 
everything to a temp folder first up, before processing it. An argument could 
be made that it should manually loop through all files and dirs, checking each 
against .Rbuildignore before copying.


From: Rainer M Krug  
Sent: Tuesday, 11 February 2020 7:38 PM
To: Gábor Csárdi 
Cc: Hong Ooi ; r-package-devel@r-project.org
Subject: [EXTERNAL] Re: [R-pkg-devel] R CMD build hanging for some but not all 
packages




On 10 Feb 2020, at 17:58, Gábor Csárdi <mailto:csardi.ga...@gmail.com> wrote:

Maybe you have large, ignored files in the package directory? R first
creates a copy of the whole directory and only applies `.Rbuildignore`
after that.



THANKS - you solved my question without me having to answer it. As I am using a 
makefile to build the package, I can easily rename the ignored directories 
before calling build.

But the question is why are these ignored directories scanned before building 
the package? They should be ignored anyway?

Rainer




Gabor

On Mon, Feb 10, 2020 at 4:54 PM Hong Ooi via R-package-devel
<mailto:r-package-devel@r-project.org> wrote:


Actually, cancel that: it finished successfully, but took 3 minutes to prepare 
the package:

r$> devtools::build()
v  checking for file 'C:\Users\hongo\Documents\GitHub\AzureStor/DESCRIPTION'
-  preparing 'AzureStor': (3m 4s)
v  checking DESCRIPTION meta-information ...
-  installing the package to build vignettes
v  creating vignettes (6.5s)
-  checking for LF line-endings in source and make files and shell scripts 
(13.8s)
-  checking for empty or unneeded directories
-  building 'AzureStor_3.1.0.9000.tar.gz'

This is really weird, I'm used to the package prep step taking 10 seconds at 
most.


-Original Message-
From: R-package-devel <mailto:r-package-devel-boun...@r-project.org> On Behalf 
Of Hong Ooi via R-package-devel
Sent: Tuesday, 11 February 2020 3:50 AM
To: mailto:r-package-devel@r-project.org
Subject: [EXTERNAL] [R-pkg-devel] R CMD build hanging for some but not all 
packages

This is with R 3.6.2 on Windows 10 Pro 1909.

In the last couple of weeks, devtools::build() and devtools::check() have 
started hanging on some, but not all, of my packages. After some poking around, 
I discovered that it's actually R CMD build that is having problems, right 
after the "checking for file 'DESCRIPTION'" step.

A reproducible example can be found by cloning my AzureStor package: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2FAzureStor&data=02%7C01%7Chongooi%40microsoft.com%7C7962d328eb984556a2e708d7aecdc0db%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637170071036915332&sdata=cmY0VPEiEgcuhI%2B4wIT8iIimQhq7751IJ0KHdsPaMtg%3D&reserved=0
 If you run "R CMD build ." in the package directory, it should hang. This is a 
relatively simple package that doesn't require compilation, although it does 
import some commonly-used packages like httr, curl, jsonlite and xml2.

As far as I can tell, R on Ubuntu works fine. What's going on?

__
mailto:R-package-devel@r-project.org mailing list
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7C7962d328eb984556a2e708d7aecdc0db%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637170071036925320&sdata=XbCKzK3no6v5asG5assjd7oxy%2BOk9or2LbS%2Fkg8GESw%3D&reserved=0

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

__
mailto:R-package-devel@r-project.org mailing list
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7C7962d328eb984556a2e708d7aecdc0db%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637170071036925320&sdata=XbCKzK3no6v5asG5assjd7oxy%2BOk9or2LbS%2Fkg8GESw%3D&reserved=0

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)
Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell:       +41 (0)78 630 66 57
mailto:rainer.k...@uzh.ch
mailto:rai...@krugs.de
Skype:     RMkrug

PGP: 0x0F52F982


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

Re: [R-pkg-devel] [EXTERNAL] Re: slightly polemic question re R CMD check

[Hong Ooi via R-package-devel]

I tend to agree. Having ... as an argument for a specific method is often 
unnecessary, and furthermore, can result in errors being hidden. Eg you think 
you're calling

methodname(arg1, arg2="whatever")

but you're really calling

methodname(arg1, ar2="whatever")

and the misspelling isn't picked up, because it gets swallowed by the ... .

IMO the whole reason for the current state of affairs is because of a wart in 
how lm and glm were implemented back in the S-Plus days. A glm object inherits 
from lm, which doesn't make a lot of sense. It should really be the other way 
round: the specific case should inherit from the general, so that an lm is a 
glm, not a glm is an lm. It's way too late to change this now, of course.


-Original Message-
From: R-package-devel  On Behalf Of 
David Hugh-Jones
Sent: Sunday, 8 March 2020 6:28 PM
To: Jeff Newmiller 
Cc: R package devel 
Subject: [EXTERNAL] Re: [R-pkg-devel] slightly polemic question re R CMD check

I see the logic, but it seems in practice people often write specific
methods with their own specific arguments. (Think of the many plot or print
methods for different objects, for example.) Here, enforcing a ... argument
does not buy us much. All that we really need is that plot(x) will work for
many classes of x. Beyond that, we expect users to read the method-specific
documentation.

Maybe this is an antipattern. It just seems that S3 methods have turned out
to be often used that way. Enforcing ... hasn't stopped it, and causes some
awkwardnesses in documentation and error checking. To be clear, I'm not
arguing against the generic having flexibility. I'm arguing against
enforcing that the method always accepts every argument that the generic
could accept.




On Sun, 8 Mar 2020, 17:14 Jeff Newmiller,  wrote:

> R encourages the use of ... particularly in S3 generics, to avoid
> over-depending on inheritance to enable flexible use of these generics.
> That is, when you call the generic without knowing which class you are
> giving it, you cannot specify class-specific arguments. However, some
> methods have obvious alternative class-specific behaviors that are
> typically enabled using class-specific arguments (e.g. plot). You cannot
> support both fully-generic calls and class-specific calls without giving
> the generic some flexibility that won't get used in some cases.
>
>
> On March 8, 2020 9:41:51 AM PDT, David Hugh-Jones <
> davidhughjo...@gmail.com> wrote:
> >Hi Jeff,
> >
> >I wouldn't say R encourages that in general. Non-generic functions will
> >throw an error if you use a non-existent argument. And some generic
> >functions check for it:
> >
> >seq(1, 3, blah = 1)
> >[1] 1 2 3
> >Warning message:
> >In seq.default(1, 3, blah = 1) :
> > extra argument ‘blah’ will be disregarded
> >
> >In fact there is even a `chkDots()` function to help with this - which,
> >despite having used R or 17 years, I first discovered today :-). So, it
> >seems the R base developers thought lenient argument checking could be
> >a
> >bad thing, presumably because it lets errors go undetected.
> >
> >Maybe chkDots is a reasonable workaround. But I wonder what the
> >rationale
> >is for R CMD check enforcing that methods *must* be as lenient as the
> >generic. It seems to lead to a lot of documentation of the form:
> >
> >@param ... Not used.
> >
> >Cheers,
> >David
> >
> >
> >On Sun, 8 Mar 2020 at 16:24, Jeff Newmiller 
> >wrote:
> >
> >> You seem to think this is a bad thing. R does encourage lenient
> >argument
> >> checking... what rock have you been under for the last 20 years?
> >>
> >> On March 8, 2020 5:41:51 AM PDT, David Hugh-Jones <
> >> davidhughjo...@gmail.com> wrote:
> >> >You're quite right :-) But I think the polemic still holds, because
> >I
> >> >have
> >> >to add manual argument checking to all my methods, which has a cost
> >in
> >> >lines of code. Indeed, few base R methods have chosen to do this. In
> >> >effect, the current setup encourages writing methods with "lenient"
> >> >argument specifications.
> >> >
> >> >Thank you for the suggestion about ellipsis.
> >> >
> >> >On Sun, 8 Mar 2020, 11:04 Gábor Csárdi, 
> >wrote:
> >> >
> >> >> You can add the ... argument to chop.default(), and then check
> >that
> >> >> length(list(...)) is zero.
> >> >>
> >> >> Also, you might be interested in the ellipsis package.
> >> >>
> >> >> Gabor
> >> >>
> >> >> On Sun, Mar 8, 2020 at 10:56 AM David Hugh-Jones
> >> >>  wrote:
> >> >> >
> >> >> > Hi all,
> >> >> >
> >> >> > My package defines the following method and generic:
> >> >> >
> >> >> > chop <- function (x, ...) UseMethod("chop")
> >> >> >
> >> >> > chop.default <- function (x, breaks, labels, extend = NULL, drop
> >=
> >> >TRUE)
> >> >> {
> >> >> > ... }
> >> >> >
> >> >> > R CMD check then gives a warning:
> >> >> >
> >> >> > W  checking S3 generic/method consistency (695ms)
> >> >> >chop:
> >> >> >  function(x, ...)
> >> >> >chop.default:
> >> >> >  function(x, breaks, labels, extend, 

[R-pkg-devel] SAR package: check errors with dataset documentation

[Hong Ooi via R-package-devel]

Hello all,

I'm refreshing the docs for my SAR package ( https://github.com/hongooi73/SAR 
), and I'm running into a weird problem.

The package contains 2 example data frames, 'ms_catalog' and 'ms_usage'. Here 
is the relevant documentation for them, in the file R/ms_data.R:

#' Sample usage dataset
#'
#' Dataset of anonymised transaction records from the Microsoft online store.
#' @format A data frame with the following variables:
#' \describe{
#'  \item{user}{The user ID.}
#'  \item{item}{The item ID, corresponding to the items in the [ms_catalog] 
dataset.}
#'  \item{time}{The date and time of the transaction, in POSIXct format.}
#' }
#' @source Microsoft.
#' @seealso
#' [ms_catalog]
"ms_usage"

#' Sample catalog dataset
#'
#' Dataset of item descriptions from the Microsoft online store.
#' @format A data frame with the following variables:
#' \describe{
#'  \item{item}{The item ID, corresponding to the items in the [ms_usage] 
dataset.}
#'  \item{name}{A short description of the item.}
#'  \item{category}{The item category.}
#' }
#' @source Microsoft.
#' @seealso
#' [ms_usage]
"ms_catalog"


When I run devtools::check() and rhub::check_for_cran(), I get a warning:

* checking for code/documentation mismatches ... WARNING
  'ms_catalog'
Variables with usage in documentation object 'ms_usage' but not in code:
Variables with usage in documentation object 'ms_catalog' but not in code:
  'ms_usage'

Can anyone see where the problem lies? As far as I can tell, I'm following the 
correct procedure for documenting datasets with Roxygen. I'm using R 4.0.0 on 
Win 10.

(I also get a note about checking artifacts left over in the check directory, 
but I'm not worried about that for the moment -- seems to be a wart with 
devtools::check().)

Hong

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

Re: [R-pkg-devel] [EXTERNAL] Re: Proper CRAN way - How to handle dependency of java jar file?

[Hong Ooi via R-package-devel]

Another possibility, if you want the jar to be dynamic and also have a standard 
location for it, is to write it to the R config/user dir. This is available via 
R_user_dir() in R 4.0 (and earlier versions via the backports package). An 
older alternative that still works is to use the rappdirs package.


-Original Message-
From: R-package-devel  On Behalf Of 
Rainer M Krug
Sent: Tuesday, 23 June 2020 10:48 PM
To: Duncan Murdoch 
Cc: R Package Devel 
Subject: [EXTERNAL] Re: [R-pkg-devel] Proper CRAN way - How to handle 
dependency of java jar file?

Thanks Duncan.

> On 23 Jun 2020, at 14:35, Duncan Murdoch  wrote:
> 
> Your assumption that .jar files are not allowed is wrong:  a number of 
> packages contain them:  rscala, J4R, Rbgs, bartMachine, OpenStreetMap, ...  
> There's a specific mention about how to include them in the CRAN policy 
> document:

That’s good to know.

> 
> "For Java .class and .jar files, the sources should be in a top-level java 
> directory in the source package (or that directory should explain how they 
> can be obtained)."

So a tet file in the inst/jar directory giving the link to the GitHub repo 
would be fine in this case?
 
> 
> If you still decide not to include your .jar file (maybe it is too big, for 
> example),


I guess it would be stretching it a bit, as the jar file is 8.2 MB, and 
plantuml has regular continuous updates, so I would prefer to keep it dynamic.


> then I think your option 1 is unusable for those people who can't write to 
> the library location because of permission problems. (Admin privileges are 
> often necessary to install packages in the main library.)  Generally I think 
> everyone can install packages somewhere, but users do really get confused 
> when they have multiple library locations, possibly each containing a 
> different version of a package.

So the suggested option would be to have a function, which 
1) ask the user to create a directory in the home folder 
2) download the jar file into that directory or, when no permission is granted, 
into the tmpdir()

Thanks, no major changes necessary for that,

Rainer
 

> 
> Duncan Murdoch
> 
> On 23/06/2020 8:18 a.m., Rainer M Krug wrote:
>> Hi
>> I have a package called `plantuml` (https://github.com/rkrug/plantuml) which 
>> converts plantuml code to UML graphs. It uses for this the java program 
>> https://plantuml.com which is Open Source.
>> As it is not allowed to distribute a binary with an R package, I use the 
>> approach of a function which downloads the jar file into the directory 
>> `system.file("jar/plantuml.jar", package = "plantuml”)`.
>> This works nicely, and at the moment, the function is called automatically 
>> before the plantuml.jar is used.
>> Now I would like to submit the package to CRAN. I can’t find the guidelines 
>> anymore, so I am asking here:
>> What is the appropriate way of handling this?
>> I can think of a at least two ways of making it obvious to the user, that a 
>> binary is downloaded:
>> 1) if the file plantuml.jar is not present, ask the user to run the function 
>> `updatePlantumlJar()` which downloads the jar to the original location in 
>> the package directory
>> 2) tell the user to download the file manually and to put it somewhere, 
>> where the package will find it
>> I would prefer the first version, as the plantuml.jar would be in the 
>> package directory, where usually nobody but the package is doing stuff.
>> Any suggestions on how I could make this “CRAN conform”?
>> Thanks a lot,
>> Rainer
>> --
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
>> UCT), Dipl. Phys. (Germany)
>> Orcid ID: -0002-7490-0066
>> Department of Evolutionary Biology and Environmental Studies
>> University of Zürich
>> Office Y34-J-74
>> Winterthurerstrasse 190
>> 8075 Zürich
>> Switzerland
>> Office:  +41 (0)44 635 47 64
>> Cell:+41 (0)78 630 66 57
>> email:  rainer.k...@uzh.ch
>>  rai...@krugs.de
>> Skype: RMkrug
>> PGP: 0x0F52F982
>> --
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
>> UCT), Dipl. Phys. (Germany)
>> Orcid ID: -0002-7490-0066
>> Department of Evolutionary Biology and Environmental Studies
>> University of Zürich
>> Office Y34-J-74
>> Winterthurerstrasse 190
>> 8075 Zürich
>> Switzerland
>> Office:  +41 (0)44 635 47 64
>> Cell:+41 (0)78 630 66 57
>> email:  rainer.k...@uzh.ch
>>  rai...@krugs.de
>> Skype: RMkrug
>> PGP: 0x0F52F982
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell: 

Re: [R-pkg-devel] [EXTERNAL] Proper CRAN way - How to handle dependency of java jar file?

[Hong Ooi via R-package-devel]

Yes, that’s the one.

From: Rainer M Krug 
Sent: Tuesday, 23 June 2020 11:12 PM
To: Hong Ooi 
Cc: R Package Devel 
Subject: Re: [EXTERNAL] [R-pkg-devel] Proper CRAN way - How to handle 
dependency of java jar file?

Thanks Hong - I like that.

I found that package in the tools::R_user_dir() package - us that the one?

Rainer



On 23 Jun 2020, at 15:07, Hong Ooi 
mailto:hong...@microsoft.com>> wrote:

Another possibility, if you want the jar to be dynamic and also have a standard 
location for it, is to write it to the R config/user dir. This is available via 
R_user_dir() in R 4.0 (and earlier versions via the backports package). An 
older alternative that still works is to use the rappdirs package.


-Original Message-
From: R-package-devel 
mailto:r-package-devel-boun...@r-project.org>>
 On Behalf Of Rainer M Krug
Sent: Tuesday, 23 June 2020 10:48 PM
To: Duncan Murdoch mailto:murdoch.dun...@gmail.com>>
Cc: R Package Devel 
mailto:r-package-devel@r-project.org>>
Subject: [EXTERNAL] Re: [R-pkg-devel] Proper CRAN way - How to handle 
dependency of java jar file?

Thanks Duncan.


On 23 Jun 2020, at 14:35, Duncan Murdoch 
mailto:murdoch.dun...@gmail.com>> wrote:

Your assumption that .jar files are not allowed is wrong:  a number of packages 
contain them:  rscala, J4R, Rbgs, bartMachine, OpenStreetMap, ...  There's a 
specific mention about how to include them in the CRAN policy document:

That’s good to know.



"For Java .class and .jar files, the sources should be in a top-level java 
directory in the source package (or that directory should explain how they can 
be obtained)."

So a tet file in the inst/jar directory giving the link to the GitHub repo 
would be fine in this case?



If you still decide not to include your .jar file (maybe it is too big, for 
example),


I guess it would be stretching it a bit, as the jar file is 8.2 MB, and 
plantuml has regular continuous updates, so I would prefer to keep it dynamic.



then I think your option 1 is unusable for those people who can't write to the 
library location because of permission problems. (Admin privileges are often 
necessary to install packages in the main library.)  Generally I think everyone 
can install packages somewhere, but users do really get confused when they have 
multiple library locations, possibly each containing a different version of a 
package.

So the suggested option would be to have a function, which
1) ask the user to create a directory in the home folder
2) download the jar file into that directory or, when no permission is granted, 
into the tmpdir()

Thanks, no major changes necessary for that,

Rainer




Duncan Murdoch

On 23/06/2020 8:18 a.m., Rainer M Krug wrote:

Hi
I have a package called `plantuml` 
(https://github.com/rkrug/plantuml)
 which converts plantuml code to UML graphs. It uses for this the java program 
https://plantuml.com
 which is Open Source.
As it is not allowed to distribute a binary with an R package, I use the 
approach of a function which downloads the jar file into the directory 
`system.file("jar/plantuml.jar", package = "plantuml”)`.
This works nicely, and at the moment, the function is called automatically 
before the plantuml.jar is used.
Now I would like to submit the package to CRAN. I can’t find the guidelines 
anymore, so I am asking here:
What is the appropriate way of handling this?
I can think of a at least two ways of making it obvious to the user, that a 
binary is downloaded:
1) if the file plantuml.jar is not present, ask the user to run the function 
`updatePlantumlJar()` which downloads the jar to the original location in the 
package directory
2) tell the user to download the file manually and to put it somewhere, where 
the package will find it
I would prefer the first version, as the plantuml.jar would be in the package 
directory, where usually nobody but the package is doing stuff.
Any suggestions on how I could make this “CRAN conform”?
Thanks a lot,
Rainer
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)
Orcid ID: -0002-7490-0066
Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland
Office:   +41 (0)44 635 47 64
Cell:  +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
   rai...@krugs.de

Re: [R-pkg-devel] [EXTERNAL] Usage of internet resources in examples

[Hong Ooi via R-package-devel]

I set \dontrun{} on (most of) the examples in my Azure-related packages, for 
this very reason. They assume the user has an Azure subscription, and in any 
case, you don't want to be running code that could potentially cost lots of 
money just for kicks. The packages in question are basically all those on CRAN 
that start with "Azure".

I cleared this with Uwe Ligges some time back; although whenever I submit a new 
package, I tend to get emails from whoever did the review that \donttest() 
should be removed. I've been able to resolve this by replying and cc'ing Uwe, 
mentioning that it was approved previously.


-Original Message-
From: R-package-devel  On Behalf Of Andy 
Teucher
Sent: Wednesday, 21 October 2020 7:29 AM
To: r-package-devel@r-project.org
Subject: [EXTERNAL] [R-pkg-devel] Usage of internet resources in examples

Our package bcdata 
(https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcran.r-project.org%2Fpackage%3Dbcdata&data=04%7C01%7Chongooi%40microsoft.com%7C3a5d0a6f36074ebfde8408d87536d145%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637388226515752313%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xxnnjkhi%2B40WOm6S9VBrAB8M4IPePX0MrvN3oosqYnA%3D&reserved=0)
 retrieves public data from British Columbia data services, so the examples are 
dependent on successfully hitting web resources. When we initially submitted to 
CRAN the examples were wrapped in \dontrun{}, but we were asked to change them 
to use \donttest{}.

 
Now, CRAN is running checks with _R_CHECK_DONTTEST_EXAMPLES_=true, and one of 
the examples has failed due to a changed web resource. I got an email asking me 
to fix it and reminding me of the CRAN policy:
 

  'Packages which use Internet resources should fail gracefully with an 
informative message

 if the resource is not available or has changed (and not give a check warning 
nor error).'

  This needs correction whether or not the resource recovers.

 
I would prefer that in normal use, the function calling the internet resources 
fails with an error so that the user is properly alerted. I also agree that 
these failures shouldn't cause a check error. To demonstrate the use of these 
functions in examples, is there a preferred method of ensuring that failures 
will not cause a check warning or error? Should I try to revert back to using 
\dontrun{} and plead my case? Wrap in `if interactive())`?
 

Thanks very much,

Andy Teucher

 
__
R-package-devel@r-project.org mailing list
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=04%7C01%7Chongooi%40microsoft.com%7C3a5d0a6f36074ebfde8408d87536d145%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637388226515752313%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qzv9k50S770BrVY%2BAAsDE8i0w8C3zW3reZtxZOJdW9E%3D&reserved=0

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

Re: [R-pkg-devel] [EXTERNAL] Re: Pre-test failure

[Hong Ooi via R-package-devel]

My personal opinion is that as long as a package doesn't actually make it on to 
CRAN, you don't need to bump the version. It's worked so far

-Original Message-
From: R-package-devel  On Behalf Of Ben 
Bolker
Sent: Saturday, 24 October 2020 2:23 AM
To: r-package-devel@r-project.org
Subject: [EXTERNAL] Re: [R-pkg-devel] Pre-test failure

Can you share the links to the CRAN pre-test logs? Someone here 
might be able to guess what went wrong ...

(FWIW I always *think* I'm testing very carefully, and I almost 
always get something wrong ...)

On 10/23/20 11:18 AM, Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:
> I test my packages very carefully before submission.  Earlier today I 
> submitted a package that passed this morning on both winbuilder_release and 
> winbuilder_devel.  The pre-test submission failed on rebuilding the vignette. 
>  I just tried again on winbuilder_release and winbuilder_devel,  no problems. 
>  There are no problems either on my Mac or a Fedora image. Moreover I tested 
> the specific lines that were flagged,  and they work fine
> 
> So my questions are:
> 
> 1.  Should I just resubmit assuming it was some kind of quirk?
> 
> 2. Do I need to bump up the version to resubmit?
> 
> Thanks,
> 
> -Roy
> 
> 
> **
> "The contents of this message do not reflect any position of the U.S. 
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pfeg.noaa.gov%2F&data=04%7C01%7Chongooi%40microsoft.com%7C05d6b3fb72074139cfd508d87767931b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637390634032310385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZhyBMECoZohEfOqkRqz%2BwV6PB560jUKurP3eXyyfugg%3D&reserved=0
> 
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
> 
> __
> R-package-devel@r-project.org mailing list
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=04%7C01%7Chongooi%40microsoft.com%7C05d6b3fb72074139cfd508d87767931b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637390634032310385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CXtC%2FqbZ0B3znnxcTHQb2voADGKPFIhl1jfTrzGl%2Ft0%3D&reserved=0
>

__
R-package-devel@r-project.org mailing list
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=04%7C01%7Chongooi%40microsoft.com%7C05d6b3fb72074139cfd508d87767931b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637390634032310385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CXtC%2FqbZ0B3znnxcTHQb2voADGKPFIhl1jfTrzGl%2Ft0%3D&reserved=0

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