Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()
Very nice discussion. Thanks, Mark. On Thu, Jul 19, 2018 at 3:20 AM, Mark van der Loo wrote: > > Dear Mike, et al, > > My remarks are not necessarily related to tidyverse packages. The main point > is that there are various purposes and business cases for writing code, and > they may imply different trade-offs. Let me illustrate with some examples. I > will focus on non-standard evaluation and dependencies. > > > TL;DR version: (and this is my opinion, nobody has to agree). > > 1/Interactive use: user-level NSE ok (as in the not-a-pipe operator, dplyr > verbs), use any package you want. > 2/Applications & local packages: avoid NSE within functions, package an > application with dependencies you need, write code with maintainers in mind. > 3/Published R-packages: avoid NSE within functions, minimize dependencies to > what you cannot avoid. > > Do Read version: > > 1/ One-off data analyses or exploratory data analyses. There are cases where > you don't need to guarantee that your code will run a few years from now: > you are the only user and once your task is done, you quickly need to move > on to the next. Especially in EDA, I write a lot of code that is nice to > keep in a structured project folder but most probably: 1) I will be its only > user and 2) I will use it only for this one small project so maintenance is > not an issue. Although I'm writing code in scripts, it is very close to > interactive work on the command-line. > > In such cases I use whatever gets the job done, including dplyr, tidyr, > ggplot2, data.table, you name it. Here I basically don't care about > dependencies and if I write functions there are usually not many of them. > > > 2/ Writing applications or packages for internal use. When you write an > application you are usually committing to a longer maintenance horizon and > more than one user. Good chance that you're not the user and also good > chance you're not the only developer. There are many implications to this > but since you need to maintain things for a longer term, dependencies can > become a liability. Fortunately, there are techniques to contain > dependencies, for example using packrat or by manually setting up a library > containing the packages your application depends on. You can even use a > docker instance. I have worked with custom libraries on several occasions. > Since you (or someone else) is going to maintain the application, it is > worth while to sit down and think what is the best way to set up code so it > remains maintainable. This includes questions like: can I easily understand > what happens when reading it? What expertise does the maintainer need to > understand it? Non-standard evaluation is generally much harder to reason > about than standard evaluated code. This makes debugging and extending code > harder in general. > > Now some people will argue that something like filter(data, x>1) is easier > to understand than data[data$x > 1,,drop=FALSE]. I agree that on a very > shallow level, filter(data, x>1) is easy to follow, in the sense of "oh the > author probably wants to filter something here". But when you are debugging, > you need to understand in much greater detail what happens: you need to know > that 'x>1' is an expression, that will be evaluated in the context of > 'data'. You need to know about environments and parent environments and so > on. All this knowledge can be avoided with data[data$x > 1,,drop=FALSE]. The > latter also requires knowledge, but the concepts are much simple I think. > > Hence, I tend to avoid NSE when writing applications, although there may > still be good reasons to do it. Dependencies can be containered in various > ways so they are not such a big problem. > > 3/ Writing packages for CRAN. Now you are committing to long-term > maintenance, and usage by interactive users, application builders, and > possibly other package builders. Now a dependency becomes a direct liability > in the sense that the author of your dependency can change interfaces and > ask you to comply to the new version. Also, and especially because of > recursive dependencies, importing a package may give you a whole tail of > dependencies. This increases load time but also install-time, especially on > systems where you need to install from source. Light-weight packages > therefore have real advantages in applications that run many times (like a > standalone script that is fired by users of a web-application or scripts > that are scheduled to run in high frequency). It is also worth mentioning > that an Imports or Depends puts a burden on the maintainer of the package > you depend on: before submitting to CRAN, a pkg developer needs to check > against all reverse dependencies (preferably recursively). > > So now, it is even more worth while to sit down and think about what is the > best way to set up your code. Well thought out code can be a pleasure to > maintain. Code that is hastily put together is a nightmare. > > My philosophy is
Re: [R-pkg-devel] C++11 and deprecated warnings "noise" for auto_ptr
Thanks Dirk, This will cut down the size of my compilation logs dramatically. On Thu, Jul 19, 2018 at 6:06 AM Iñaki Úcar wrote: > Great! Many thanks for sharing this, Dirk. > > Iñaki > El jue., 19 jul. 2018 a las 14:37, Dirk Eddelbuettel > () escribió: > > > > > > As some of you may have noticed, or may have been told as well in kind > "fix > > this or else ..." email, 'R CMD check' now also marks g++-7 / g++-8 > warnings > > of 'deprecated declarations'. > > > > This can of course be addressed in the code itself, or suppressed with > the > > '-Wno-deprecated-declarations' flag in compiler options in eg > ~/.R/Makevars. > > > > A particularly annoying case is in all the code depending on Boost > headers > > and using eg our BH package. I just installed an updated new package from > > CRAN and again had screens full of warnings for 'deprecated > std::auto_ptr'. > > > > Looking at the Boost header file, it turns out that for this case one > can use > > the '-DBOOST_NO_AUTO_PTR' define and the compilation will be silent! So > those > > of us using Boost and BH could add the define to the headers. > > > > 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 > > > > -- > Iñaki Úcar > http://www.enchufa2.es > @Enchufa2 > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Running R CMD CHECK on different architectures
On 19/07/2018 10:20 AM, Stuart Lacy via R-package-devel wrote: I've just submitted a new release of my package multistateutils to CRAN but have received an automated email back asking if I've fixed the errors from the previous release. Firstly, why was the previous release accepted onto CRAN if it had errors? Iñaki answered your main question. For this first question, there are several possible explanations. The most common one is that the tests have become more stringent than they were at the previous submission. It's also possible that there has been a big enough change in R or one of the compilers or other tools that something that worked before no longer works. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Running R CMD CHECK on different architectures
--- Begin Message --- Hi, I've just submitted a new release of my package multistateutils to CRAN but have received an automated email back asking if I've fixed the errors from the previous release. Firstly, why was the previous release accepted onto CRAN if it had errors? The result of the check on the previous release is available here https://cran.r-project.org/web/checks/check_results_multistateutils.html However, the errors and warnings are in architectures that I don't have available, i.e. r-devel on fedora, r-patched solaris, r-release osx, r-oldrel osx. How can I test that these errors have been fixed in my latest version? I run CMD CHECK through devtools::check() and also test on win-builder and there are no problems on either of these. Thanks, Stuart -- Stuart Lacy Research Fellow Epidemiology and Cancer Statistics Group University of York 01904 321118 Disclaimer: http://www.york.ac.uk/docs/disclaimer/email.htm --- End Message --- __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] C++11 and deprecated warnings "noise" for auto_ptr
Great! Many thanks for sharing this, Dirk. Iñaki El jue., 19 jul. 2018 a las 14:37, Dirk Eddelbuettel () escribió: > > > As some of you may have noticed, or may have been told as well in kind "fix > this or else ..." email, 'R CMD check' now also marks g++-7 / g++-8 warnings > of 'deprecated declarations'. > > This can of course be addressed in the code itself, or suppressed with the > '-Wno-deprecated-declarations' flag in compiler options in eg ~/.R/Makevars. > > A particularly annoying case is in all the code depending on Boost headers > and using eg our BH package. I just installed an updated new package from > CRAN and again had screens full of warnings for 'deprecated std::auto_ptr'. > > Looking at the Boost header file, it turns out that for this case one can use > the '-DBOOST_NO_AUTO_PTR' define and the compilation will be silent! So those > of us using Boost and BH could add the define to the headers. > > 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 -- Iñaki Úcar http://www.enchufa2.es @Enchufa2 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] C++11 and deprecated warnings "noise" for auto_ptr
As some of you may have noticed, or may have been told as well in kind "fix this or else ..." email, 'R CMD check' now also marks g++-7 / g++-8 warnings of 'deprecated declarations'. This can of course be addressed in the code itself, or suppressed with the '-Wno-deprecated-declarations' flag in compiler options in eg ~/.R/Makevars. A particularly annoying case is in all the code depending on Boost headers and using eg our BH package. I just installed an updated new package from CRAN and again had screens full of warnings for 'deprecated std::auto_ptr'. Looking at the Boost header file, it turns out that for this case one can use the '-DBOOST_NO_AUTO_PTR' define and the compilation will be silent! So those of us using Boost and BH could add the define to the headers. 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
[R-pkg-devel] Documentation with roxygen2
Dear all, this period I am working as a student on a Google Summer of Code project. We develop an Rcpp package. I am trying to create a documentation as a pdf using roxygen2. I add the comments #' above of each R function and generate the Rd files with roxygwn2::roxygenise() function. Then I run in the command line R CMD Rd2pdf --pdf --title='Title of package' --description -o /tmp/packahe.pdf man/*.Rd And a pdf is creating. But I can not create a package description with the info from description file and a table of contents at the beginning of the document. What I am doing wrong? Thanks in advance, Tolis [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()
Dear Mike, et al, My remarks are not necessarily related to tidyverse packages. The main point is that there are various purposes and business cases for writing code, and they may imply different trade-offs. Let me illustrate with some examples. I will focus on non-standard evaluation and dependencies. TL;DR version: (and this is my opinion, nobody has to agree). 1/Interactive use: user-level NSE ok (as in the not-a-pipe operator, dplyr verbs), use any package you want. 2/Applications & local packages: avoid NSE within functions, package an application with dependencies you need, write code with maintainers in mind. 3/Published R-packages: avoid NSE within functions, minimize dependencies to what you cannot avoid. Do Read version: 1/ One-off data analyses or exploratory data analyses. There are cases where you don't need to guarantee that your code will run a few years from now: you are the only user and once your task is done, you quickly need to move on to the next. Especially in EDA, I write a lot of code that is nice to keep in a structured project folder but most probably: 1) I will be its only user and 2) I will use it only for this one small project so maintenance is not an issue. Although I'm writing code in scripts, it is very close to interactive work on the command-line. In such cases I use whatever gets the job done, including dplyr, tidyr, ggplot2, data.table, you name it. Here I basically don't care about dependencies and if I write functions there are usually not many of them. 2/ Writing applications or packages for internal use. When you write an application you are usually committing to a longer maintenance horizon and more than one user. Good chance that you're not the user and also good chance you're not the only developer. There are many implications to this but since you need to maintain things for a longer term, dependencies can become a liability. Fortunately, there are techniques to contain dependencies, for example using packrat or by manually setting up a library containing the packages your application depends on. You can even use a docker instance. I have worked with custom libraries on several occasions. Since you (or someone else) is going to maintain the application, it is worth while to sit down and think what is the best way to set up code so it remains maintainable. This includes questions like: can I easily understand what happens when reading it? What expertise does the maintainer need to understand it? Non-standard evaluation is generally much harder to reason about than standard evaluated code. This makes debugging and extending code harder in general. Now some people will argue that something like filter(data, x>1) is easier to understand than data[data$x > 1,,drop=FALSE]. I agree that on a very shallow level, filter(data, x>1) is easy to follow, in the sense of "oh the author probably wants to filter something here". But when you are debugging, you need to understand in much greater detail what happens: you need to know that 'x>1' is an expression, that will be evaluated in the context of 'data'. You need to know about environments and parent environments and so on. All this knowledge can be avoided with data[data$x > 1,,drop=FALSE]. The latter also requires knowledge, but the concepts are much simple I think. Hence, I tend to avoid NSE when writing applications, although there may still be good reasons to do it. Dependencies can be containered in various ways so they are not such a big problem. 3/ Writing packages for CRAN. Now you are committing to long-term maintenance, and usage by interactive users, application builders, and possibly other package builders. Now a dependency becomes a direct liability in the sense that the author of your dependency can change interfaces and ask you to comply to the new version. Also, and especially because of recursive dependencies, importing a package may give you a whole tail of dependencies. This increases load time but also install-time, especially on systems where you need to install from source. Light-weight packages therefore have real advantages in applications that run many times (like a standalone script that is fired by users of a web-application or scripts that are scheduled to run in high frequency). It is also worth mentioning that an Imports or Depends puts a burden on the maintainer of the package you depend on: before submitting to CRAN, a pkg developer needs to check against all reverse dependencies (preferably recursively). So now, it is even more worth while to sit down and think about what is the best way to set up your code. Well thought out code can be a pleasure to maintain. Code that is hastily put together is a nightmare. My philosophy is as follows: I depend other packages only when they offer something that I cannot fairly trivially do myself. This may have to do with a statistical or numerical method I do not want or cannot implement, or it can have something to do with performance for
