similar to: Runnable R packages

Yesterday I wrote and submitted to CRAN a package `run`, which implements the ideas discussed in this thread. Given a package tarball foo_0.1.0.tar.gz, users will be able to run Rscript -e "run::run('foo_0.1.0.tar.gz')" which will pull all the dependencies of package `foo`, lookup a function `main` in that package's namespace, and call it. It's an early draft but

I see some value in Duncan?s proposal to implement this as an extra package instead of a change to base R, if only to see if the idea has legs. I?m minded to do so myself using your suggestion, but is there a particular reason why you recommend using the remotes package instead of devtools? The latter seems to have the same functions I would need, and I believe it is more widely installed that

On 02/02/2019 8:27 a.m., Barry Rowlingson wrote: > I don't think anyone denies that you *could* make an EXE to do all > that. The discussion is on *how easy* it should be to create a single > file that contains an initial "main" function plus a set of bundled > code (potentially as a package) and which when run will install its > package code (which is contained in

Sounds interesting. Do you have it on GitHub or similar? Rainer > On 8 Feb 2019, at 09:09, David Lindelof <lindelof at ieee.org> wrote: > > Yesterday I wrote and submitted to CRAN a package `run`, which implements > the ideas discussed in this thread. Given a package tarball > foo_0.1.0.tar.gz, users will be able to run > > Rscript -e

Doesn't Rtools provide everything needed to build R packages and R on Windows - including gcc? Am Sa., 2. Feb. 2019 um 22:29 Uhr schrieb Abs Spurdle <spurdle.a at gmail.com>: > Creating an .exe file isn't necessarily difficult. > The main problems are that you have to write and compile the C (or other) > files. > Otherwise, the complexity depends on the level of Inter

On Mon, 7 Jan 2019 at 22:09, Gergely Dar?czi <daroczig at rapporter.net> wrote: > > Dear David, sharing some related (subjective) thoughts below. > > You can provide your app as a Docker image, so that the end-user > simply calls a "docker pull" and then "docker run" -- that can be done > from a user-friendly script as well. > Of course, this requires

Creating an .exe file isn't necessarily difficult. The main problems are that you have to write and compile the C (or other) files. Otherwise, the complexity depends on the level of Inter Process Communication that's required. Simply starting R with some initial conditions, is easy. Even if you want to prompt the user to install missing packages, it isn't necessarily difficult. It

Would you care to share how your package installs its own dependencies? I assume this is done during the call to `main()`? (Last time I checked, R CMD INSTALL would not install a package's dependencies...) On Thu, Jan 31, 2019 at 4:38 PM Barry Rowlingson < b.rowlingson at lancaster.ac.uk> wrote: > > > On Thu, Jan 31, 2019 at 3:14 PM David Lindelof <lindelof at ieee.org>

Dear all, I?m working as a data scientist in a major tech company. I have been using R for almost 20 years now and there?s one issue that?s been bugging me of late. I apologize in advance if this has been discussed before. R has traditionally been used for running short scripts or data analysis notebooks, but there?s recently been a growing interest in developing full applications in the

Further to my previous post, it would be possible to create an .exe file, say: my_r_application.exe That starts R, loads your R package(s), calls the R function of your choice and does whatever else you want. However, I don't think that it would add much value. But feel free to correct me if you think that I'm wrong. [[alternative HTML version deleted]]

Ummm oops. Magic pixies? It assumed all of CRAN was installed? Maybe I'll write something that could go in /usr/lib/R/bin/RUN that checks and gets deps, installs the package, and runs package::main, which I think is what the OP wants - you could do R CMD RUN foo_1.0.0.tar.gz and away it goes... B On Thu, Jan 31, 2019 at 3:56 PM David Lindelof <lindelof at ieee.org> wrote: > >

To download a package with all its dependencies and install it, use the install.packages() functions instead of 'R CMD INSTALL'. E.g., in bash: mkdir /tmp/libJunk env R_LIBS_SITE=libJunk R --quiet -e 'if (!requireNamespace("purrr",quietly=TRUE)) install.packages("purrr")' For corporate "production use" you probably want to set up your own repository

On 16/12/2016 12:35 PM, Karl Millar wrote: > A couple of points: > - rebuilding dependent packages is needed if there is an ABI change, > not just an API change. For packages like Rcpp which export inline > functions or macros that might have changed, this is potentially any > change to existing functions, but for packages like Matrix, it isn't > really an issue at all

Hello, If anyone would like it I have provided a Dovecot 1.0 test61 port and package for FreeBSD 5.3 here. I made them for my own experimentation but thought they might be interesting to others I suppose. http://www.helenmarks.co.uk/~dom/dovecot/ These deviate from the stock test61 because I've updated and added a patch I wrote a long time ago for ioloop kqueue/kevent support in

Hi all, I am trying to package a library in R 1.6.1 (Windoze XP). I have read the document "Writing R extensions" and think I have done things correctly (though apparently not). I have searched the mail archives for help to no avail. When I try to attach the library using, eg > library( libname, lib.loc=path.to.library) I get this message: Warning message: NAs introduced by

Hello, I have some troubles when building S4-class packages. All my (S4-)code works well (without building a package). When building a package, in the R prompt after checking S3 generic/method consistency Following error occurs: Fehler: Kann R Kode in Packet 'AddNoise' nicht laden (~Error: Can not load R code from package 'AddNoise') (and there are some warnings after the

Belated thanks to all who replied to my initial query. In summary, three approaches have been mentioned to run R code "in production": 1) ShinyProxy, mentioned by Tobias, for deploying Shiny applications; 2) Docker-like solutions, mentioned by Gergely and I?aki; and 3) Solutions based on Rscript or littler, mentioned by Dirk. I can't speak to 1) because I don't currently use

On Thu, Jan 31, 2019 at 3:14 PM David Lindelof <lindelof at ieee.org> wrote: > > In summary, I'm convinced R would benefit from something similar to Java's > `Main-Class` header or Python's `__main__()` function. A new R CMD command > would take a package, install its dependencies, and run its "main" > function. I just created and built a very

Dear David, sharing some related (subjective) thoughts below. On Mon, Jan 7, 2019 at 9:53 PM David Lindelof <lindelof at ieee.org> wrote: > > Dear all, > > I?m working as a data scientist in a major tech company. I have been using > R for almost 20 years now and there?s one issue that?s been bugging me of > late. I apologize in advance if this has been discussed before.

Would Studio 10, or Studio 11 be preferable to build? This message posted from opensolaris.org