Re: [R-pkg-devel] Package submission to CRAN

[Brodie Gaslam via R-package-devel]

I would just increment the version.  This is the from the CRAN
re-submission policy[1]:

> Updates to previously-published packages must have an increased version. 
> Increasing the version number at each submission reduces confusion so is 
> preferred even when a previous submission was not accepted.

You could always add NEWS entry explaining what the new version
is, then the package will not be exactly the same anymore ;).

Best,

B.


[1]: https://cran.r-project.org/web/packages/policies.html#Re_002dsubmission



On Tuesday, October 19, 2021, 08:38:01 AM EDT, Simon Bonner 
 wrote: 





Hi all,

I have a question re package submission that I'm hoping someone might be able 
to help with.

A package I maintain (dalmatian) was archived last year because one of the 
packages it depends on (dglm) was removed from CRAN. The dglm package has been 
fixed and is back on CRAN, and I have resubmitted my package. There have been 
no changes to my package and I resubmitted the same version with the same 
version number. I noted this in my submission.

All checks passed, but I received the following from log CRAN-pretest:

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: CRAN incoming feasibility, Result: WARNING
  Maintainer: 'Simon Bonner simon.bon...@uwo.ca'

  New submission

  Package was archived on CRAN

  Insufficient package version (submitted: 0.6.1, existing: 0.6.1)

  CRAN repository db overrides:
    X-CRAN-Comment: Archived on 2020-10-18 as requires archived package
      'dglm'.

  This build time stamp is over a month old.

It seems that I am not allowed to submit the package with the same version, but 
 it also seems odd to increment the version to get around this when nothing at 
all has changed in the package.

Is there another solution?

Thanks,

Simon

-
Simon Bonner (he/him)
Associate Professor of Environmetrics
Vice-Director, Western Data Science Solutions
Department of Statistical and Actuarial Sciences
University of Western Ontario

Office: Western Science Centre rm 276

Email: sbonn...@uwo.ca | Telephone: 519-661-2111 x88205 
| Fax: 519-661-3813
Twitter: @bonnerstatslab | Website: http://simon.bonners.ca/bonner-lab/wpblog/


    [[alternative HTML version deleted]]

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

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

Re: [R-pkg-devel] system.file duplicates the path

[brodie gaslam via R-package-devel]

Fabio,

Judging from prior versions of your package, the function `tile_read`
makes many assumptions as to what paths will look like, and also
modifies paths.  In this case, it appears to be thrown off by either
the lower case drive name, or the forward slashes in the path.  Presumably
winbuilder is now running in a configuration that does different things
with paths.

Under those new paths, your code will double up the path by pre-pending
the current working directory.  This is not a `system.file` issue.

I just took the second part of (grabbed from the error message):

'd:/RCompile/CRANincoming/R-devel/uFTIR.Rcheck/d:/RCompile/CRANincoming/R-devel/lib/uFTIR/extdata/tile.bsp'

and fed it to your function from the prior version of your package
and was able to produce a doubled up path as above.

Best,

B.

PS: with this type of thing it is always helpful if you can provide a
link to an online repository with the version of the code that you
are trying to submit.




On Friday, September 3, 2021, 12:29:02 PM EDT, Fabio Corradini S. 
 wrote: 





Dear All:

I submitted a package to CRAN. I developed it in DEBIAN and tested it in
R-HUB windows devel, windows release, and macOS. None of the systems throw
an
error to me, and I mainly get notes about the package archived condition.

However, the package failed at win-builder devel, as in one of the tests I
call
base::system.file to read a file and the function --only there-- returns
the file
path twice.

Does system.file work differently on windows?

You can check out CRAN win-builder check.log at:
<
https://win-builder.r-project.org/incoming_pretest/uFTIR_0.1.3_20210903_174243/Windows/00check.log
>

Kind regards,
Fabio

-- 


    [[alternative HTML version deleted]]

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

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

Re: [R-pkg-devel] (R-devel unknown warning: 'memory.limit()' is no longer supported)

[brodie gaslam via R-package-devel]

Or you might need to make their use conditional on the R
version.  It is possible that the call is still needed if your
package is run on older versions of R.  I am not familiar with
the general use of this though.  I only noticed the change
in R-devel and linked it to your question.

Best,

B.


On Friday, September 3, 2021, 12:18:35 PM EDT, brodie gaslam 
 wrote: 


There was a recent changed made to R to remove that option.
There is documentation visible in the patch that explains it:

https://github.com/r-devel/r-svn/commit/795fb3fe60d35734750afbc34cc7d36b19290b9c

Presumably you would have to remove any uses of the now
unsupported functions.  After the patch, the only thing those
functions do is issue the warning.

Best,

B.


On Friday, September 3, 2021, 11:39:03 AM EDT, Cristhian Paredes Cardona 
 wrote: 



Dear All,

I'm trying to submit an R package to CRAN and there is a new warning that
did not use to appear a few days ago when checking with winbuilder (R under
development version):

Found the following significant warnings:
  Warning: 'memory.limit()' is no longer supported
See 'd:/RCompile/CRANincoming/R-devel/masscor.Rcheck/00install.out' for details.

Package build is attached and Check results when the warning did not
appear are at: https://win-builder.r-project.org/2zQe5ZnEci31/

I would appreciate if someone could please provide me with some guide
on how to solve this issue.

Thanks in advance.

Sincerely,

Cristhian Paredes

-- 
*Aviso legal:* El contenido de este mensaje y los archivos adjuntos son 
confidenciales y de uso exclusivo de la Universidad Nacional de Colombia. 
Se encuentran dirigidos sólo para el uso del destinatario al cual van 
enviados. La reproducción, lectura y/o copia se encuentran prohibidas a 
cualquier persona diferente a este y puede ser ilegal. Si usted lo ha 
recibido por error, infórmenos y elimínelo de su correo. Los Datos 
Personales serán tratados conforme a la Ley 1581 de 2012 y a nuestra 
Política de Datos Personales que podrá consultar en la página web 
www.unal.edu.co .* *Las opiniones, informaciones, 
conclusiones y cualquier otro tipo de dato contenido en este correo 
electrónico, no relacionados con la actividad de la Universidad Nacional de 
Colombia, se entenderá como personales y de ninguna manera son avaladas por 
la Universidad.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] (R-devel unknown warning: 'memory.limit()' is no longer supported)

[brodie gaslam via R-package-devel]

There was a recent changed made to R to remove that option.
There is documentation visible in the patch that explains it:

https://github.com/r-devel/r-svn/commit/795fb3fe60d35734750afbc34cc7d36b19290b9c

Presumably you would have to remove any uses of the now
unsupported functions.  After the patch, the only thing those
functions do is issue the warning.

Best,

B.


On Friday, September 3, 2021, 11:39:03 AM EDT, Cristhian Paredes Cardona 
 wrote: 



Dear All,

I'm trying to submit an R package to CRAN and there is a new warning that
did not use to appear a few days ago when checking with winbuilder (R under
development version):

Found the following significant warnings:
  Warning: 'memory.limit()' is no longer supported
See 'd:/RCompile/CRANincoming/R-devel/masscor.Rcheck/00install.out' for details.

Package build is attached and Check results when the warning did not
appear are at: https://win-builder.r-project.org/2zQe5ZnEci31/

I would appreciate if someone could please provide me with some guide
on how to solve this issue.

Thanks in advance.

Sincerely,

Cristhian Paredes

-- 
*Aviso legal:* El contenido de este mensaje y los archivos adjuntos son 
confidenciales y de uso exclusivo de la Universidad Nacional de Colombia. 
Se encuentran dirigidos sólo para el uso del destinatario al cual van 
enviados. La reproducción, lectura y/o copia se encuentran prohibidas a 
cualquier persona diferente a este y puede ser ilegal. Si usted lo ha 
recibido por error, infórmenos y elimínelo de su correo. Los Datos 
Personales serán tratados conforme a la Ley 1581 de 2012 y a nuestra 
Política de Datos Personales que podrá consultar en la página web 
www.unal.edu.co .* *Las opiniones, informaciones, 
conclusiones y cualquier otro tipo de dato contenido en este correo 
electrónico, no relacionados con la actividad de la Universidad Nacional de 
Colombia, se entenderá como personales y de ninguna manera son avaladas por 
la Universidad.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] package test returns error when R version 4.1.0

[brodie gaslam via R-package-devel]

> On Tuesday, July 6, 2021, 8:09:18 AM EDT, dbosa...@gmail.com 
>  wrote:
>
> Martin:
>
> What I suggested was he remove the LazyData entry from the description file
> if he was NOT lazy loading data.  If someone is lazy loading data, then that
> is a different situation, and they obviously need to set the entry.
>
> But clearly Gm has a different problem.  He has now tried "LazyData: true",
> "LazyData: false", and removing the LazyData entry entirely.  And he is
> still getting this error:
>
> * installing *source* package 'movecost' ...
> ** using staged installation
> ** R
> ** data
> ** byte-compile and prepare package for lazy loading
> ERROR: lazy loading failed for package 'movecost'
> * removing 'd:/RCompile/CRANguest/R-release/lib/movecost'

FWIW I think this is lazy loading of the code, which I think is
 different to what LazyData controls.  This is described in 
R-Internals:

https://cran.r-project.org/doc/manuals/R-ints.html#Lazy-loading

I know nothing about it so I will not comment further.

Best,

B.

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

Re: [R-pkg-devel] Unable to get past CRAN submission checks for package cubature

[brodie gaslam via R-package-devel]

At the risk of only being mildly (if at all) helpful, I was able
to reproduce your warnings on Rhub, which has the same compiler,
with:

    rhub::check('cubature_2.0.4.1.tar.gz', platform='windows-x86_64-release')

Absent feedback from CRAN you could try tweaking your code so that
it does not produce those warnings while no changing behavior.
Obviously, iterating with rhub is not the easiest way to do this,
but might be easier than trying to get GCC 8.3.

For reference, you might be hitting:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273

Maybe you knew that already but it might be useful for others to be
aware there is an actual bug that at least is in the general area
that affects GCC 8.2-8.3.

Best,

B.




On Monday, May 10, 2021, 4:01:36 PM EDT, Balasubramanian Narasimhan 
 wrote: 





I submitted a minor update of cubature (suggesting rmarkdown for 
vignettes) and received a message that the package generated warnings. 
However, the warnings were noted to be untrustworthy (see email below). 
I noted this in the submission comments as well as the reply to the 
auto-check email.

It appears that I am unable to get beyond the auto-check service. Any 
suggestions?

-Naras

 Forwarded Message 

Subject:     Re: [CRAN-pretest-archived] CRAN submission cubature 2.0.4.2
Date:     Thu, 6 May 2021 12:51:37 -0700
From:     Balasubramanian Narasimhan 
To:     cran-submissi...@r-project.org, na...@stat.stanford.edu



Dear CRAN,

As explained in my submission comment, the warning is noted to be flaky 
in the message below.

Thank you.

-Naras

On 18/03/2021 13:05, Kurt Hornik wrote:

>> Uwe Ligges writes:
>
>> Dear Naras,
>> your package cubature shows compiler warnings under Windows:
>> 
>
>> Any chance getting rid of these? Please try and resubmit.
>
> Interestingly, r-release-macos shows this too ...

I think -Warray-bounds is known to be flaky in earlier compilers.  I do 
not see this on macOS with Apple Clang 11.5 (latest for High Sierra) or 
12.4 (current) and nor does Tomas for GCC 10 on Windows.


-- 
Brian D. Ripley, rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
On 5/6/21 12:27 PM, lig...@statistik.tu-dortmund.de wrote:
> Dear maintainer,
>  
> package cubature_2.0.4.2.tar.gz does not pass the incoming checks 
> automatically, please see the following pre-tests:
> Windows:
> Status: 1 WARNING
> Debian:
> Status: OK
>  
> Last released version's CRAN status: WARN: 3, NOTE: 10
> See:
>  
> CRAN Web:
>  
> 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:
> 
> The files will be removed after roughly 7 days.
>  
> *** Strong rev. depends ***: ALTopt apTreeshape bivquant BNSP calibrator 
> clusteredinterference coga cold dbmss DRAYL dvmisc ei equivalenceTest 
> fMultivar GAS GB2 GPCMlasso GRCdata highfrequency hyper2 ICAOD inctools 
> MCMCglmm MIRES MMDCopula MWright NonNorMvtDist np OBASpatial ODS optimStrat 
> PCMRS planar pooling Power2Stage PowerTOST ProFit QGglmm robustlmm skedastic 
> SphericalCubature spNetwork statsr SurvDisc symmoments TCIU tseriesEntropy 
> UPCM vines WLinfer yuima
>  
> Best regards,
> CRAN teams' auto-check service
>
> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
> Check: CRAN incoming feasibility, Result: Note_to_CRAN_maintainers
>    Maintainer: 'Balasubramanian Narasimhan'
>
> Flavor: r-devel-windows-ix86+x86_64
> Check: whether package can be installed, Result: WARNING
>    Found the following significant warnings:
>      ./src/common/Random.c:105:5: warning: 'memcpy' pointer overflow between 
>offset 0 and size [4294967292, 2147483647] [-Warray-bounds]
>      ./src/common/Random.c:105:5: warning: 'memcpy' pointer overflow between 
>offset 0 and size [-4, 9223372036854775807] [-Warray-bounds]
>    See 'd:/RCompile/CRANincoming/R-devel/cubature.Rcheck/00install.out' for 
>details.

    [[alternative HTML version deleted]]

__
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

Re: [R-pkg-devel] Problems with too much testing

[brodie gaslam via R-package-devel]

An all.equal method?  This might not work with 3rd edition though
(untested), and I'm not sure what method registration requirements
would exist for the user.

Best,

B.

On Friday, April 16, 2021, 6:09:24 AM EDT, Duncan Murdoch 
 wrote: 





I'm updating the rgl package, and have come across the following problem.

Some packages that depend on rgl and do careful testing are detecting 
inconsequential changes.  A typical case is the nat package, which has 
extensive testing, some of which comes down to checking results from rgl 
functions using testthat::is_equal().  I rewrote some parts of the rgl 
code, and so some rgl objects differ in irrelevant ways.  For example,

  obj <- list(x = NULL)

differs from

  obj <- list()
  obj[["x"]] <- NULL

(the first is length 1, the second ends up with no entries).  All tests 
in rgl would be like

  if (is.null(obj[["x"]])) ...

so the tests evaluate the same, but testthat::is_equal() doesn't return 
TRUE, because the objects are different.

Another example would be

  obj <- list()
  obj$a <- 1
  obj$b <- 2

which differs from

  obj <- list()
  obj$b <- 2
  obj$a <- 1

in the order of the components, but since rgl always accessed them by 
name, that makes no difference.

So what I'm looking for is a strategy to hide internal implementation 
details.  (I'm using a compare_proxy() method now which standardizes the 
objects, but that seems very specific to testthat version 3.  I'd like 
ideas for something more robust.)

Duncan Murdoch

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

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

Re: [R-pkg-devel] Accessing features in R4.0.

[brodie gaslam via R-package-devel]

I don't know if this will work in your case (or even if it is a good
or bad thing to do), but backports conditionally exports the function
in question, e.g.:

https://github.com/r-lib/backports/blob/master/R/lengths.R

So in that example their implementation of a function not available
in R < 3.2.0 is presumably only exported for those versions of R.
You could try something similar, although I make no guarantees
on whether this is considered proper or not.  It _seems_ like
a clean solution to me, but I have no experience putting any
logic in the namespace file.

WRE does show something very similar, so this might be okay:

https://cran.r-project.org/doc/manuals/R-exts.html#Registering-S3-methods

Best,

B.



On Wednesday, December 16, 2020, 11:29:08 AM EST, Colin Gillespie 
 wrote: 





Hi,

I'm planning on using the tools::R_user_dir function in a package. But
for obvious reasons, I don't want to set the dependency on R 4.

My code is basically

if (as.numeric(R.version$major) < 4) # do something
else tools::R_user_dir("oysteR", which = "cache")

When checking on win-builder R3.6 I get the note

* checking dependencies in R code ... NOTE
Missing or unexported object: 'tools::R_user_dir'

## Question

Is my code correct and can I ignore this note?

Thanks

Colin


Dr Colin Gillespie
http://www.mas.ncl.ac.uk/~ncsg3/

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

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

Re: [R-pkg-devel] Winbuilder queues jammed again?

[brodie gaslam via R-package-devel]

You can also just paste the ftp link into your browser.






On Thursday, March 5, 2020, 6:31:03 PM EST, Rolf Turner 
 wrote: 






On 6/03/20 11:41 am, Henrik Bengtsson wrote:

> 1. I'd guess it helps Uwe a bit you clarify exactly which queue you 
> think is stuck - otherwise he has to check them all. They're independent.

Yeah.  Sorry.  It's the R-release queue.

> 2. You can look at the different win-builder queues yourself via ftp, 
> see https://stat.ethz.ch/pipermail/r-package-devel/2020q1/005098.html

That could be useful information, but when I tried just now I could not 
get curl to work:

> curl -s ftp://win-builder.r-project.org/R-release/
> curl: /usr/local/lib/libcurl.so.4: no version information available (required 
> by curl)
> curl: relocation error: curl: symbol curl_mime_headers version CURL_OPENSSL_4 
> not defined in file libcurl.so.4 with link time reference

I then tried

    sudo apt update
    sudo apt upgrade
    sudo apt install curl

according to some instructions that I found on the web.  It told me "

> curl is already the newest version (7.58.0-2ubuntu3.8).
> 0 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade.

I then did

curl --version

and got

> curl: /usr/local/lib/libcurl.so.4: no version information available (required 
> by curl)
> curl: relocation error: curl: symbol curl_mime_headers version CURL_OPENSSL_4 
> not defined in file libcurl.so.4 with link time reference

I've Googled about a bit and found various references, but nothing that 
I could understand or use.

I don't understand what's going on/wrong.  Nor do I understand why the 
Computer Gods hate me! :-)


cheers,

Rolf

-- 
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

__
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

[R-pkg-devel] Possible gcc-10.0.1 Bug in gcc-10 Test Server

[brodie gaslam via R-package-devel]

At the risk of getting laughed out of the room I wanted to share with you some 
interesting findings that arose from trying to figure out why my package vetr 
is segfaulting on the gcc-10 test machine:

https://www.stats.ox.ac.uk/pub/bdr/gcc10/vetr.out

Thanks to Dirk Eddelbuettel who pointed me to rocker/r-base that builds on the 
testing debian repo I was able to reproduce the error, and figure just enough 
to post a semi-cogent question on SO:

https://stackoverflow.com/q/60406042/2725969

And some folks that know more than me about compilers rendered judgment that it 
likely is a compiler error.  I realize "random dudes on SO rendered judgment" 
is not exactly the most ringing endorsement, but the logic they present is 
sound and matches my reading of the C standard (not that that is worth much).

It is unlikely for others to run into this issue as it requires an extremely 
particular set of circumstances.  If you too segfault on Professor Ripley's 
machine please don't just point to this as the reason without actually 
confirming that's what's happening.

Best,

Brodie.

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

Re: [R-pkg-devel] Installing "Additional" Packages During Tests

[brodie gaslam via R-package-devel]

--- Begin Message ---
 I believe your first point makes the alternate workflow below illegal, but the 
subsequent ones add just enough ambiguity that I'd like to makes sure.  How 
about:
0. Only during the running of tests
1. Create a temporary directory tmplib using tempfile()/dircreate().
2. Install dummy package to that temporary directory using `lib=tmplib`: 
install.packages(srcdir, type='src', repos=NULL, lib=tmplib).
3. In the tests, use library(testpkg, lib.loc=tmplib)4. unload / remove / 
unlink temp directory on.exit
This is only in the test running.  None of the code in the package proper that 
the user would invoke in normal use installs packages.  It only happens if the 
user installs and runs the tests, and with the above modification, it would 
only be into a temporary library directory.
Thank you for your patience and attention.
Best,
Brodie.


On Monday, March 18, 2019, 11:56:55 AM EDT, Uwe Ligges 
 wrote:  
 
 1. You should never install packages without asking the user.

2. a package should never write to the user file space or default 
libraries unless the user akss for it explicitly.
In tests, use tempdir().

3. You cannot expect that the library is writeable. It is not in many 
network installations.

Best,
Uwe Ligges



On 18.03.2019 16:48, brodie gaslam via R-package-devel wrote:
> 
> Subject:
> Installing "Additional" Packages During Tests
> From:
> brodie gaslam 
> Date:
> 18.03.2019, 16:48
> To:
> List R-package-devel 
> 
> To:
> List R-package-devel 
> 
> 
> Sorry, previous e-mail got pre-maturely sent due to fat finger...
> My package unitizer[1] has recently gained the following type of error:
>   Warning in install.packages(pkg, repos = NULL, type = "src") : 'lib 
>= "/home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages"' is not writable
>   Error in install.packages(pkg, repos = NULL, type = "src") :
>   unable to install packages
> 
> While I did recently update the package to resolve the RNGversion issue, this 
> problem seems unrelated as some of the CRAN machines produce it, and some 
> don't, on the same package version.
> The tests install some dummy packages with `install.packages`, and this has 
> worked for a long time, but no longer, presumably due to changes in 
> permissions of the test running daemon.  The packages are removed on.exit.  
> The packages are used for integration tests as unitizer is a 
> package-testing-package and it is useful to be able to test functionality 
> that includes use on actual packages that change.
> 
> Should I expect this to be the new normal, where I will be henceforth 
> disallowed from installing packages temporarily?  Will there be an acceptable 
> workaround (e.g. setting up a temporary library in a tempdir and try to 
> `install.packages` into that; I admit I have no familiarity with this other 
> than the vague awareness maybe this could be done)?
> FWIW, perhaps an indication that this is something I shouldn't be doing came 
> up earlier in the year when I had to resort to temporarily unsetting 
> "R_TESTS" as per [2].
> Thanks in advance for any input.
> Best,
> Brodie.
> 
> 
> [1]: https://cran.r-project.org/web/checks/check_results_unitizer.html[2]: 
> https://github.com/r-lib/testthat/issues/144
>     [[alternative HTML version deleted]]
> 
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
  
[[alternative HTML version deleted]]

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

[R-pkg-devel] Installing "Additional" Packages During Tests

[brodie gaslam via R-package-devel]

--- Begin Message ---
Sorry, previous e-mail got pre-maturely sent due to fat finger...
My package unitizer[1] has recently gained the following type of error:
 Warning in install.packages(pkg, repos = NULL, type = "src") : 'lib = 
"/home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages"' is not writable
 Error in install.packages(pkg, repos = NULL, type = "src") : 
 unable to install packages

While I did recently update the package to resolve the RNGversion issue, this 
problem seems unrelated as some of the CRAN machines produce it, and some 
don't, on the same package version.
The tests install some dummy packages with `install.packages`, and this has 
worked for a long time, but no longer, presumably due to changes in permissions 
of the test running daemon.  The packages are removed on.exit.  The packages 
are used for integration tests as unitizer is a package-testing-package and it 
is useful to be able to test functionality that includes use on actual packages 
that change.

Should I expect this to be the new normal, where I will be henceforth 
disallowed from installing packages temporarily?  Will there be an acceptable 
workaround (e.g. setting up a temporary library in a tempdir and try to 
`install.packages` into that; I admit I have no familiarity with this other 
than the vague awareness maybe this could be done)?
FWIW, perhaps an indication that this is something I shouldn't be doing came up 
earlier in the year when I had to resort to temporarily unsetting "R_TESTS" as 
per [2].
Thanks in advance for any input.
Best,
Brodie.


[1]: https://cran.r-project.org/web/checks/check_results_unitizer.html[2]: 
https://github.com/r-lib/testthat/issues/144
[[alternative HTML version deleted]]

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

[R-pkg-devel] Installing Additional "Packages" During Tests

[brodie gaslam via R-package-devel]

--- Begin Message ---
My package unitizer has recently gained a new set of errors that look like:

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] CRAN check FAIL due to pragmas in headers and code

[brodie gaslam via R-package-devel]

--- Begin Message ---
I too am seeing the same failure in my package.  It does not contain any 
#pragma directives, and it doesn't have any dependencies to other compiled 
packages.
Poking around through the CRAN checks I've found other packages with C compiled 
code displaying the same error on the clang and gcc 64 bit debian checks:
* diffobj: (my package) 
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/diffobj-00check.html*
 xts: 
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/xts-00check.html*
 backports: 
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/backports-00check.html
I'm pretty sure (but not certain) that my package did not throw these errors as 
of quite recently (I uploaded to CRAN over the weekend).

This leads me to think that it is (maybe) possible that this is an issue with 
the latest version of the check tool?
Best,
Brodie.

[[alternative HTML version deleted]]

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

[R-pkg-devel] A package that traces base functions

[brodie gaslam via R-package-devel]

--- Begin Message ---
Apologies, this is a cross post from 'R-devel', where I sent this message a few 
months ago when I did not realize there was an 'r-package-devel' list.  So here 
it is again in the correct list:

I'm working on a package that implements a REPL.  A typical interaction with 
the package might look like:
> launch_REPL()REPL> 1 + 1[1] 2REPL> QDo you wish to save results? [y/n]REPL> 
> ygoodbye ...>
This is very similar to what happens when in `browser()`: the REPL evaluates 
arbitrary R user expressions and offers some additional commands.
In order to implement functionality required for the REPL I must trace some 
functions in the base package.  The trace is removed `on.exit()` from the REPL, 
so the functions are only modified while the `launch_REPL` function is 
evaluating.  Unfortunately this is against the letter of the law (as per CRAN 
policy):
> A package must not tamper with the code already loaded into R: anyattempt to 
> change code in the standard and recommended packages whichship with R is 
> prohibited.
Is there any chance that this very limited (only during my function evaluation) 
modification of base functions with `trace` could be considered to meet the 
spirit of the law, if not the letter?  Package users would be duly notified 
this is happening.
Alternatively, if this is not allowed, would it be acceptable to ship the 
functionality turned off by default with a user option to enable it (documented 
with warnings about how this is non-standard behavior, etc.)?

Regards,
Brodie Gaslam.
PS: More details for those who care: the REPL among other things implements an 
environment that has for parent `as.environment(2)` so that objects in the 
global environment are not visible while in the REPL, but otherwise the full 
search path is.  Anytime the search path changes I need to update the REPL 
environment to re-point to `as.environment(2)`, which means I need to know when 
the search path changes.  I do this by tracing `library`/`attach`/`detach` and 
triggering a side effect that updates the REPL environment parent any time 
those are called.  The search path itself is untouched.  I cannot just parse 
user expressions searching for those functions as the user can use any 
arbitrary expressions, including sourcing files that contain the `library`, 
etc. calls.  
[[alternative HTML version deleted]]

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