Re: [R-pkg-devel] Submission to CRAN when package needs personal data (API key)
On 2018-09-08 14:02, Joshua Ulrich wrote: Hi Rainer, On Wed, Sep 5, 2018 at 2:28 AM, Rainer Krug wrote: 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? I have a similar issue with quantmod. I need API keys to test some functionality and I would like the tests run regularly, so I can know when something breaks without having to wait for a user to report the change. I store the API keys in encrypted environment variable in TravisCI, and I check for those environment variables before running the tests that require them. Then I added a cron job on TravisCI to run the build if there hasn't been a build in the past 24 hours. That solves the problem adequately for my purposes without adding any burden to CRAN. Hopefully it works for your purposes too. So those tests don't run if the required environment variables are not there? Rainer's problem was getting a secure time stamp. For his case, rather than skip the tests if the API keys were not there, one might take the time stamp from someplace else, perhaps with a note of the source of the time stamp. Spencer Best, Josh 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: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 __ 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] Submission to CRAN when package needs personal data (API key)
On Fri, Sep 7, 2018 at 2:53 PM Iñaki Ucar wrote: [...] > 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." And while deprecated, this method still works just fine, and will continue to work. You can just put your tests in inst/tests/testthat and put withr::with_dir( system.file(package = , "tests"), testthat::test_check()) in tests/testthat.R. And of course you can run the tests of the installed package with the same piece of code. Gabor > Iñaki > > > > > Dirk > > > > -- > > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Submission to CRAN when package needs personal data (API key)
Hi Rainer, On Wed, Sep 5, 2018 at 2:28 AM, Rainer Krug wrote: > 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? > I have a similar issue with quantmod. I need API keys to test some functionality and I would like the tests run regularly, so I can know when something breaks without having to wait for a user to report the change. I store the API keys in encrypted environment variable in TravisCI, and I check for those environment variables before running the tests that require them. Then I added a cron job on TravisCI to run the build if there hasn't been a build in the past 24 hours. That solves the problem adequately for my purposes without adding any burden to CRAN. Hopefully it works for your purposes too. Best, Josh > 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: rai...@krugs.de > Skype: RMkrug > > PGP: 0x0F52F982 > > > > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2018 | www.rinfinance.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Submission to CRAN when package needs personal data (API key)
On 08/09/2018 2:06 PM, Dirk Eddelbuettel wrote:
On 7 September 2018 at 13:08, Gábor Csárdi wrote:
| On Fri, Sep 7, 2018 at 12:29 PM Dirk Eddelbuettel 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.
|
| > 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.
When you set up a test runner it all works just as intended, and has for a
decade or so (see below for a demo of timeDate by the late Diethelm Wuertz).
I feel rather strongly that this is in fact an area where we as a community
failed to elevate our best practices. But as the cheesy saying goes: "The
best time to plant a tree was 20 years ago. The second best time is now."
I agree with this.
Duncan Murdoch
Dirk
Demo below runs off the _installed_ package which is a rather neat feature we
could stress more for more complete regression and rev.dep tests.
R> library(RUnit) ## needed to run all tests
R> ts <- defineTestSuite(name="timeDate", dirs=system.file("unitTests",
package="timeDate"))
R> library(timeDate) ## needed for code to be tested and its Depends
R> res <- runTestSuite(ts)
Executing test function test.asDate ... GMT
[1] [2006-06-01] [2006-12-01]
[1] "2006-06-01" "2006-12-01"
NewYork
[1] [2006-06-01] [2006-12-01]
[1] "2006-06-01" "2006-12-01"
done successfully.
[... lots omitted as RUnit is verbose ...]
Executing test function test.AAA ... [1] "Pacific/Auckland"
done successfully.
R> res
Number of test functions: 56
Number of errors: 1
Number of failures: 0
R>
|
| Gabor
|
| [...]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Submission to CRAN when package needs personal data (API key)
On 7 September 2018 at 13:08, Gábor Csárdi wrote:
| On Fri, Sep 7, 2018 at 12:29 PM Dirk Eddelbuettel 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.
|
| > 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.
When you set up a test runner it all works just as intended, and has for a
decade or so (see below for a demo of timeDate by the late Diethelm Wuertz).
I feel rather strongly that this is in fact an area where we as a community
failed to elevate our best practices. But as the cheesy saying goes: "The
best time to plant a tree was 20 years ago. The second best time is now."
Dirk
Demo below runs off the _installed_ package which is a rather neat feature we
could stress more for more complete regression and rev.dep tests.
R> library(RUnit) ## needed to run all tests
R> ts <- defineTestSuite(name="timeDate", dirs=system.file("unitTests",
package="timeDate"))
R> library(timeDate) ## needed for code to be tested and its Depends
R> res <- runTestSuite(ts)
Executing test function test.asDate ... GMT
[1] [2006-06-01] [2006-12-01]
[1] "2006-06-01" "2006-12-01"
NewYork
[1] [2006-06-01] [2006-12-01]
[1] "2006-06-01" "2006-12-01"
done successfully.
[... lots omitted as RUnit is verbose ...]
Executing test function test.AAA ... [1] "Pacific/Auckland"
done successfully.
R> res
Number of test functions: 56
Number of errors: 1
Number of failures: 0
R>
|
| Gabor
|
| [...]
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
