Skip to content

[R-pkg-devel] Submission to CRAN when package needs personal data (API key)

38 messages · Uwe Ligges, Peter Meissner, Henrik Bengtsson +11 more

Original

Messages 1–25 of 38

Rainer M Krug
# 
Hi

I have a package at GitHub (https://github.com/rkrug/ROriginStamp) which I am pre[paring for CRAN.

It creates a trusted timestamp using the API fro OriginStamp (https://originstamp.org/home) which requires an API key. Now this API should not be made public, as to much traffic through one API key will lead to it?s blocking.

I have stored the key encrypted in the travis.yml, and the package passes all tests.

But if I send it to CRAN, it would fail the tests, as the api key is not in the package itself.

I could disable all tests for CRAN which need the API key, but I think it would be better tu run the tests there as well (as an additional check to travis).

My question:

Is there a way of storing the API key encrypted, so that only the CRAN test servers can decrypt it, or is there another way can steal with this?

Thanks,

Rainer



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

University of Z?rich

Cell:       +41 (0)78 630 66 57
email:      Rainer at krugs.de
Skype:      RMkrug

PGP: 0x0F52F982




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://stat.ethz.ch/pipermail/r-package-devel/attachments/20180905/6c66a463/attachment.sig>
Uwe Ligges
# 
You should not run on CRAN. Note that the checks are done almost daily 
oin several platforms, hence the API key is used for about 10 check runs 
a day.

Best,
Uwe Ligges
On 05.09.2018 09:28, Rainer Krug wrote:
Rainer M Krug
# 
OK - thanks. I will than disable the checks for CRAN.

Thanks,

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

University of Z?rich

Cell:       +41 (0)78 630 66 57
email:      Rainer at krugs.de
Skype:      RMkrug

PGP: 0x0F52F982




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://stat.ethz.ch/pipermail/r-package-devel/attachments/20180905/56c43181/attachment.sig>
Peter Meissner
# 
Hey,

Maybe webmockr (or something alike) can help:
https://cran.r-project.org/web/packages/webmockr/index.html

Best, Peter

Rainer M Krug <Rainer at krugs.de> schrieb am Mi., 5. Sep. 2018, 15:38:

  
  


  


      

    

    

      
      

        


  

        

      Spencer Graves
    

    

      
      #
    

  


  

      
The fda package disables some tests on CRAN using:


if(!fda::CRAN()){
 ??? test you don't want run on CRAN
}


 ????? I've used this in other contexts with tests that are too long to 
run on CRAN but that I want to run otherwise during "R CMD check".


 ????? Spencer Graves

        
On 2018-09-05 12:13, Peter Meissner wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Gábor Csárdi
    

    

      
      #
    

  


  

      
On Wed, Sep 5, 2018 at 6:34 PM Spencer Graves

        
<spencer.graves at effectivedefense.org> wrote:

            

      
      
      
    

        
Seemingly this just checks for a couple of (5 by default) environment
variables that match "^_R_":
https://github.com/cran/fda/blob/0549e6a86aa144d8c2aade2d8704a269fb8a94ed/R/CRAN.R#L14

I am not sure if this is a good indication of the machine being a CRAN
machine, I do set  some of these
occasionally on my machine.  It would be great if CRAN machines could
set a specific environment
variable globally, e.g. ON_CRAN, or _R_ON_CRAN_, so people could skip
these tests and examples
easily.

Gabor

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Spencer Graves
    

    

      
      #
    

  


  

      
On 2018-09-05 12:52, G?bor Cs?rdi wrote:

            

      
      
      
    

        
Agreed.? Before I wrote that function, I asked this list for 
suggestions.? The suggestion I got was, "Don't do it."? I felt that was 
not acceptable so wrote what I did.? I think we need a better solution.? 
Spencer

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Henrik Bengtsson
    

    

      
      #
    

  


  

      
I take a complementary approach; I condition on, my home-made,
R_TEST_ALL variable.  Effectively, I do:

if (as.logical(Sys.getenv("R_TEST_ALL", "FALSE"))) {
   ...
}

and set R_TEST_ALL=TRUE when I want to run that part of the test.  You
can also imagine refined versions of this, e.g. R_TEST_SETS=foo,bar
and test scripts with:

if ("foo" %in% strsplit(Sys.getenv("R_TEST_SETS"), split="[, ]+")[[1]]) {
   ...makes no assumption
}

That avoids making assumptions on where the tests are submitted/run,
may it be CRAN, Bioconductor, Travis CI, ...

/Henrik

On Wed, Sep 5, 2018 at 11:08 AM Spencer Graves

        
<spencer.graves at effectivedefense.org> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 05/09/2018 2:20 PM, Henrik Bengtsson wrote:

            

      
      
      
    

        
This is the right way to do it.

This discussion has come up before.  If you want to submit to CRAN, you 
should include tests that satisfy their requests.  If you want even more 
tests, there are several ways to add them in addition to the CRAN tests. 
  Henrik's is one, "R CMD check --test-dir=myCustomTests" is another.

Rainer's package is unusual, in that from his description it can't 
really work unless the user obtains an API key.  There are other 
packages like that, and those cases need manual handling by CRAN:  they 
don't really run full tests by default.  But the vast majority of 
packages should be able to live within the CRAN guidelines.

Duncan Murdoch

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Rainer M Krug
    

    

      
      #
    

  


  

          

      
      
      
    

        
Thanks Henrik - that sounds like a good idea. At the moment, I am checking for the name of my machine, which is obviously not to robust.

I will implement this before submission to CRAN.

Thanks,

Rainer

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

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

University of Z?rich

Cell:       +41 (0)78 630 66 57
email: ? ? ?Rainer at krugs.de <mailto:Rainer at krugs.de>
Skype:      RMkrug

PGP: 0x0F52F982





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

University of Z?rich

Cell:       +41 (0)78 630 66 57
email:      Rainer at krugs.de
Skype:      RMkrug

PGP: 0x0F52F982




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://stat.ethz.ch/pipermail/r-package-devel/attachments/20180906/67a737a4/attachment.sig>

  
  


  


      

    

    

      
      

        


  

        

      Thierry Onkelinx
    

    

      
      #
    

  


  

      
Dear Rainer,

It looks like you are using testthat. testthat has a skip_on_cran()
function. This will always skip the subsequent tests in the script unless
the environment variable NOT_CRAN is set.

Best regards,

Thierry


ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkelinx at inbo.be
Havenlaan 88 bus 73, 1000 Brussel
www.inbo.be

///////////////////////////////////////////////////////////////////////////////////////////
To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey
///////////////////////////////////////////////////////////////////////////////////////////

<https://www.inbo.be>

2018-09-06 8:30 GMT+02:00 Rainer M Krug <Rainer at krugs.de>:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Rainer M Krug
    

    

      
      #
    

  


  

      
Correct - I should have thought that there is a Hadley-solution to this problem.

Thanks,

Rainer

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

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

University of Z?rich

Cell:       +41 (0)78 630 66 57
email:      Rainer at krugs.de
Skype:      RMkrug

PGP: 0x0F52F982




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://stat.ethz.ch/pipermail/r-package-devel/attachments/20180906/1d6f8891/attachment.sig>

  
  


  


      

    

    

      
      

        


  

        

      Hadley Wickham
    

    

      
      #
    

  


  

      
On Wed, Sep 5, 2018 at 3:03 PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:

            

      
      
      
    

        
I would like to gently push back on this assertion: if CRAN set an
environment variable we would have one single convention that all
packages could rely on. The current system relies on each package
author evolving their own solution. This makes life difficult when you
are running local reverse dependency checks: there is no way to
systematically assert that you want to run tests in a way as similar
as possible to CRAN.

I know that the CRAN maintainers already have a very large workload,
and I hate to add to it, but setting CRAN=1 in a few profile files
doesn't seem excessively burdensome.

            

      
      
      
    

        
10 years ago, I would have definitely supported this statement. But I
am not sure it is still correct today, as there are now many packages
that require a connection to web API to work (or depend on a package
that uses an API). Additionally, CRAN only allows a limited amount of
compute time for each check, so there are often longer tests that you
want to run locally but not on CRAN. CRAN is a specialised testing
service and it does have different constraints to your local machine,
travis, and bioconductor.

A quick search of the CRAN mirror on github
(https://github.com/search?q=org%3Acran+skip_on_cran&type=Code)
reveals that there are ~2700 tests that use testthat::skip_on_cran().
This is obviously an underestimate of the total number of tests
skipped on CRAN, as many packages don't use testthat, or use an
alternative technique to avoid running code on CRAN.

Hadley

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 06/09/2018 10:32 AM, Hadley Wickham wrote:

            

      
      
      
    

        
When packages delete tests just for CRAN, the quality of the repository 
suffers.  Users should be able to check an install by running the tests 
that passed on CRAN and seeing them pass on their system as well.

  The current system relies on each package

            

      
      
      
    

        
Most packages don't need to evolve anything:  the CRAN tests are sufficient.

            

      
      
      
    

        
It would be easy to do that, but then CRAN wouldn't be testing the same 
things that users would test.  A user might see a test failure that 
didn't happen on CRAN, and suspect that there was something wrong with 
their install, when in fact it was an author trying to hide a deficiency 
in their package from CRAN.

            

      
      
      
    

        
That's not so obviously an underestimate, as packages that use that 
technique use it many times, not just once per package.  (A sample I 
looked at averaged 15 calls per package, but I don't know if that's 
unbiased.)

But in any case, the skip_on_cran() function implements a version of 
Henrik's approach.  The name of the function is misleading, it doesn't 
attempt to distinguish between CRAN and a regular user.

Duncan Murdoch

  
  


  


      

    

    

      
      

        


  

        

      David Hugh-Jones
    

    

      
      #
    

  


  

      
On Fri, 7 Sep 2018 at 01:16, Duncan Murdoch <murdoch.duncan at gmail.com>
wrote:

            

      
      
      
    

        
In my limited experience there are usually tests that can't run on CRAN
 because they take too long, rely on external software or configuration
that is absent, or just fail on CRAN only (which is naturally hard to
debug). This seems normal, and having the ability to turn off some tests is
useful. The fact that multiple workarounds have evolved to do this suggests
that the need is widespread.

            

      
      
      
    

        
Sent from Gmail Mobile

  
  


  


      

    

    

      
      

        


  

        

      Rainer M Krug
    

    

      
      #
    

  


  

          

      
      
      
    

        
Absolutely. But in some cases. But t the moment, one is forced to use workarounds if test **can** not be run on CRAN (API keys, computing times, ?) but should be run on local tests. It would make much more sense if there would be a standardised way of dealing with this.

            

      
      
      
    

        
Also agreed - so if the user sets the environmental variable CRAN for the test, the CRAN tests are executed (as today), if not set, the extended tests are executed.

            

      
      
      
    

        
But there seems to be a need to exclude certain tests, due to various reasons.

            

      
      
      
    

        
See my comment above.

            

      
      
      
    

        
Only if they execute the extended tests. I can still hide deficiencies in my package by not applying a specific test or doctoring the result, if that is my intention. But the extended tests could be used to test additional setup options, which can not be tested on CRAN.

            

      
      
      
    

        
I would guess because it can?t. If there would be a standardised way of identifying that the test is run on CRAN, I would use this immediately.

Cheers,

Rainer

            

      
      
      
    

        

      
      
    

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

University of Z?rich

Cell:       +41 (0)78 630 66 57
email:      Rainer at krugs.de
Skype:      RMkrug

PGP: 0x0F52F982




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://stat.ethz.ch/pipermail/r-package-devel/attachments/20180907/226b02ce/attachment.sig>

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 07/09/2018 2:18 AM, David Hugh-Jones wrote:

            

      
      
      
    

        
I think it's useful to think of 3 groups who might run tests:

  - authors
  - CRAN
  - other users of a package.

What Hadley was arguing for is that CRAN should identify itself to a 
package, so that by default a package could run different tests for
CRAN than for other users.  I am arguing that they should run the same 
tests by default.

Clearly authors might want more extensive tests like the ones you mention.

I think it would be a good thing if a standard method evolved for others 
to ask for those tests as well.  That suggestion was made and support 
for it was added to R back in 2014.  So far standardization hasn't 
happened, which could indicate that it isn't really needed, or just that 
nobody has bothered to push for it.

Duncan Murdoch

  
  


  


      

    

    

      
      

        


  

        

      Gábor Csárdi
    

    

      
      #
    

  


  

      
On Fri, Sep 7, 2018 at 9:01 AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:

        
[...]

            

      
      
      
    

        
When are users running tests for packages at all? The tests are by default
no even installed with the package. The only time I usually do this is when
running reverse dependency checks. In this specific case I can easily set
ON_CRAN as well, if I want to replicate the CRAN tests. Or, maybe even better,
I don't set it, and run the extended test suite to potentially catch more
breakage.

            

      
      
      
    

        
If they don't set ON_CRAN (which they already don't),  then they get the
extended test suite by default.

Gabor

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      David Hugh-Jones
    

    

      
      #
    

  


  

      
On Fri, 7 Sep 2018 at 09:01, Duncan Murdoch <murdoch.duncan at gmail.com>
wrote:

            

      
      
      
    

        
This seems like the crux. But there are occasions when authors want to
single out CRAN. Sometimes things just don't work on CRAN; the exact config
of CRAN servers is not always clear, so debugging can be hard; at some
point, it just gets easier to say skip_on_cran() or the equivalent. (The
same applies to some degree for e.g. appveyor/travis). I appreciate this is
an imperfect workaround. If the CRAN config were exactly reproducible eg
via a docker image, perhaps it wouldn't be necessary.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Spencer Graves
    

    

      
      #
    

  


  

      
On 2018-09-07 01:18, David Hugh-Jones wrote:

            

      
      
      
    

        
????? Almost a decade ago I was told that certain tests in the fda 
package took too much time on CRAN.? I was NOT going to hammer on my 
co-authors to make those tests shorter.? I was happy I got those tests 
at all!? So I wrote fda::CRAN() and for those tests that took too long, 
I wrapped them in


if(!CRAN()){
 ? (tests that took too long to run on CRAN)
}


 ????? I did it after being told repeatedly, (a) you cannot run those 
tests on CRAN, and (b) you should not use that function "CRAN()"! Since 
then, I've had other occasions to use it.


 ????? Spencer Graves

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 7 September 2018 at 09:27, G?bor Cs?rdi wrote:

        
| When are users running tests for packages at all? The tests are by default
| no even installed with the package. The only time I usually do this is when

Which some people consider to be the wrong decision by testthat.

Base R has a set of functions

   tools::testInstalledBasic
   tools::testInstalledPackage
   tools::testInstalledPackages

so that an _installed_ package can be tested.  Unless, of course, it uses
testthat.  Matt Dowle just run into this (per a question on StackOverflow).
RUnit, on the other hand, supports this.

Being able to test installed packages is useful when you change any upstream
dependency (may as author of a dependency), change a system library, change
the R version, or are simply diligent about your system.

Removing the ability to do so, or requiring a reinstallation (via a temporary
or permanent setting of another options) of the package, does not help in
that matter.

| running reverse dependency checks. In this specific case I can easily set
| ON_CRAN as well, if I want to replicate the CRAN tests. Or, maybe even better,
| I don't set it, and run the extended test suite to potentially catch more
| breakage.
| 
| > Clearly authors might want more extensive tests like the ones you mention.
| >
| > I think it would be a good thing if a standard method evolved for others
| > to ask for those tests as well.
| 
| If they don't set ON_CRAN (which they already don't),  then they get the
| extended test suite by default.

I have mentioned this a few times in the past but here is what Rcpp does in a
_fully automated manner_

   1. By default a limited number of tests are running to keep the run-time
      of 'R CMD check' short enough.

   2. Unless you define an override environment variable (which we do eg for
      Travis CI) and extended tests are running (eg in development)

   3. Or unless the package version signals a development version in which
      the environment variable gets set and extended are running.

The check for 'development' version is simple: interim version are labelled
as eg right now 0.12.18.2 having _four_ components. We infer a development
version.   Release version like 0.12.18 on CRAN only ever have three.  So we
can test and automate.  This is not perfect, but it is a step up from having
to define
 
Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Gábor Csárdi
    

    

      
      #
    

  


  

      
On Fri, Sep 7, 2018 at 12:29 PM Dirk Eddelbuettel <edd at debian.org> wrote:

            

      
      
      
    

        
How is testthat related to this? When you `R CMD INSTALL` a package,
AFAICT it does not install the test by default. Independently of what
testsuite you use.

            

      
      
      
    

        
I am probably missing sg, but is this expected to run the Rcpp test suite?

tools::testInstalledPackage("Rcpp", types = "tests")

Because it takes 1ms to run and has no output.

Gabor

[...]

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 07/09/2018 4:27 AM, G?bor Cs?rdi wrote:

            

      
      
      
    

        
I do sometimes, but I do agree this is a rare case.  So why does it need 
to be distinguished from CRAN?

  The tests are by default

            

      
      
      
    

        
They should be in the tarball, which is what I would be starting with 
when I wanted to run the tests.

The only time I usually do this is when

            

      
      
      
    

        
I think we are just getting repetitive now.  The question is whether the 
tests reported on CRAN should be the defaults or special ones.  You (and 
Hadley) think they should be a special subset.  I think they should be 
the default ones, and the author should be free to define one or more 
sets of more extensive tests to run on request.

Since CRAN is famously uncommunicative and unresponsive to suggested 
changes, I think the current state of affairs (which suits my 
preferences) will continue.  So why not make it easier to live with, by 
promoting a standard way to request special tests, rather than 
continuing to beat this dead horse?

Duncan Murdoch

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 7 September 2018 at 13:08, G?bor Cs?rdi wrote:

        
| On Fri, Sep 7, 2018 at 12:29 PM Dirk Eddelbuettel <edd at debian.org> wrote:

        
| >
| >

        
| > On 7 September 2018 at 09:27, G?bor Cs?rdi wrote:

        
| > | When are users running tests for packages at all? The tests are by default
| > | no even installed with the package. The only time I usually do this is when
| >
| > Which some people consider to be the wrong decision by testthat.
| 
| How is testthat related to this? When you `R CMD INSTALL` a package,
| AFAICT it does not install the test by default. Independently of what
| testsuite you use.

I presume you know the other per the bottom part of the email. Following the
(very early best practive started by P Grosjean, M Maechler and others)
tests/doRUnit.R always calls out to files in inst/tests or inst/unitTests.

Which. Get. Installed.

For every user. Automatically.  A much better default.
 
| > Base R has a set of functions
| >
| >    tools::testInstalledBasic
| >    tools::testInstalledPackage
| >    tools::testInstalledPackages
| >
| > so that an _installed_ package can be tested.  Unless, of course, it uses
| > testthat.  Matt Dowle just run into this (per a question on StackOverflow).
| > RUnit, on the other hand, supports this.
| 
| I am probably missing sg, but is this expected to run the Rcpp test suite?
| 
| tools::testInstalledPackage("Rcpp", types = "tests")
| 
| Because it takes 1ms to run and has no output.

You probably need a) the required env var set and b) the RUnit test runner to
loop over RUnit tests and c) make sure the dependent C++ files are compiled
first which is why we have a wrapper in that package.  But note that I never
claimed it currently worked -- that test setup (being able to run from tests/
and once installed) is more tricky for Rcpp due to the compilation.

I did claim that by not giving the testthat user that option you are not helping.
And I stand by that.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Iñaki Ucar
    

    

      
      #
    

  


  

      
El vie., 7 sept. 2018 a las 15:28, Dirk Eddelbuettel
(<edd at debian.org>) escribi?:

            

      
      
      
    

        
For the record, this is what the testthat paper in the R Journal says:

"[...] I recommend storing your tests in inst/tests/ (so users also
have access to them), then including one file in tests/ that runs all
of the package tests. The test_package(package_name) function makes
this easy. [...] This setup has the additional advantage that users
can make sure your package works correctly in their run-time
environment."

I?aki