Re: [Rd] Runnable R packages
I'm not sure whether GCC is in Rtools or not. I will check on Monday. However, that's not the main point. In Rtools, there's nothing like the following: R CMD Rpkg2exe -o my_r_application.exe my_r_package or R CMD Rpkg2exe -o my_r_application.exe my_r_package_0.1.0.tar.gz Which would convert an R package into an executable file. On Thu, Feb 7, 2019 at 9:38 PM Peter Meissner wrote: > Doesn't Rtools provide everything needed to build R packages and R on > Windows - including gcc? > >> >> [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
Sure, you can find it here: https://github.com/dlindelof/run On Fri, Feb 8, 2019 at 9:41 AM Rainer M Krug wrote: > Sounds interesting. Do you have it on GitHub or similar? > > Rainer > > On 8 Feb 2019, at 09:09, David Lindelof 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 "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'd appreciate any feedback (once its submission is > accepted, of course). > > Thanks all for your help and advice, > > David > > On Sat, Feb 2, 2019 at 3:37 PM Duncan Murdoch > wrote: > > 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 itself, its not in a repo), > install dependencies, and run the main() function. > > Now, I could build a self-executable shar file that bundled a package > together with a script to do all the above. But if there was a "RUN" > command in R, and a convention that a function called "foo::main" > would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much > easier to develop and test. > > > I don't believe the "so much easier" argument that this requires a > change to base R. If you put that functionality into a package, then > the only extra effort the user would require is to install that other > package. After that, they could run > > Rscript -e "yourpackage::run_main('foo_1.1.1.tar.gz')" > > as I suggested before. This is no harder than running > > R CMD RUN foo_1.1.1.tar.gz > > The advantage of this from R Core's perspective is that you would be > developing and maintaining "yourpackage", you wouldn't be passing the > burden on to them. The advantage from your perspective is that you > could work with whatever packages you liked. The "remotes" package has > almost everything you need so that "yourpackage" could be nearly > trivial. You wouldn't need to duplicate it within base R. > > Duncan Murdoch > > > If people think this adds value, then if they want to offer that value > to me as $ or £, I'd consider writing it if their total value was more > than my cost > > Barry > > > On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle wrote: > > > 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]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc > (Conservation Biology, UCT), Dipl. Phys. (Germany) > > Department of Evolutionary Biology and Environmental Studies > University of Zürich > Office Y34-J-74 > Winterthurerstrasse 190 > 8075 Zürich > Switzerland > > Office: +41 (0)44 635 47 64 > Cell:+41 (0)78 630 66 57 > email: rainer.k...@uzh.ch > rai...@krugs.de > Skype: RMkrug > > PGP: 0x0F52F982 > > > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
Sounds interesting. Do you have it on GitHub or similar? Rainer > On 8 Feb 2019, at 09:09, David Lindelof 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 "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'd appreciate any feedback (once its submission is > accepted, of course). > > Thanks all for your help and advice, > > David > > On Sat, Feb 2, 2019 at 3:37 PM Duncan Murdoch > wrote: > >> 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 itself, its not in a repo), >>> install dependencies, and run the main() function. >>> >>> Now, I could build a self-executable shar file that bundled a package >>> together with a script to do all the above. But if there was a "RUN" >>> command in R, and a convention that a function called "foo::main" >>> would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much >>> easier to develop and test. >> >> I don't believe the "so much easier" argument that this requires a >> change to base R. If you put that functionality into a package, then >> the only extra effort the user would require is to install that other >> package. After that, they could run >> >> Rscript -e "yourpackage::run_main('foo_1.1.1.tar.gz')" >> >> as I suggested before. This is no harder than running >> >> R CMD RUN foo_1.1.1.tar.gz >> >> The advantage of this from R Core's perspective is that you would be >> developing and maintaining "yourpackage", you wouldn't be passing the >> burden on to them. The advantage from your perspective is that you >> could work with whatever packages you liked. The "remotes" package has >> almost everything you need so that "yourpackage" could be nearly >> trivial. You wouldn't need to duplicate it within base R. >> >> Duncan Murdoch >> >>> >>> If people think this adds value, then if they want to offer that value >>> to me as $ or £, I'd consider writing it if their total value was more >>> than my cost >>> >>> Barry >>> >>> >>> On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle wrote: 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]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Department of Evolutionary Biology and Environmental Studies University of Zürich Office Y34-J-74 Winterthurerstrasse 190 8075 Zürich Switzerland Office: +41 (0)44 635 47 64 Cell: +41 (0)78 630 66 57 email: rainer.k...@uzh.ch rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 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'd appreciate any feedback (once its submission is accepted, of course). Thanks all for your help and advice, David On Sat, Feb 2, 2019 at 3:37 PM Duncan Murdoch wrote: > 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 itself, its not in a repo), > > install dependencies, and run the main() function. > > > > Now, I could build a self-executable shar file that bundled a package > > together with a script to do all the above. But if there was a "RUN" > > command in R, and a convention that a function called "foo::main" > > would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much > > easier to develop and test. > > I don't believe the "so much easier" argument that this requires a > change to base R. If you put that functionality into a package, then > the only extra effort the user would require is to install that other > package. After that, they could run > > Rscript -e "yourpackage::run_main('foo_1.1.1.tar.gz')" > > as I suggested before. This is no harder than running > > R CMD RUN foo_1.1.1.tar.gz > > The advantage of this from R Core's perspective is that you would be > developing and maintaining "yourpackage", you wouldn't be passing the > burden on to them. The advantage from your perspective is that you > could work with whatever packages you liked. The "remotes" package has > almost everything you need so that "yourpackage" could be nearly > trivial. You wouldn't need to duplicate it within base R. > > Duncan Murdoch > > > > > If people think this adds value, then if they want to offer that value > > to me as $ or £, I'd consider writing it if their total value was more > > than my cost > > > > Barry > > > > > > On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle wrote: > >> > >> 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]] > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
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 : > 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 be possible to take this one step further, and write an .exe > builder, that automates the process of creating .exe files. > Obviously, it would require a compiler and supporting libraries. > I have a preference for GCC, and I'm not sure if you can run GCC on Windows > without Cygwin. > > I may (or may not) look into this further, in a few weeks time. > > > On Sun, Feb 3, 2019 at 2:27 AM Barry Rowlingson < > b.rowling...@lancaster.ac.uk> 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 itself, its not in a repo), > > install dependencies, and run the main() function. > > > > Now, I could build a self-executable shar file that bundled a package > > together with a script to do all the above. But if there was a "RUN" > > command in R, and a convention that a function called "foo::main" > > would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much > > easier to develop and test. > > > > If people think this adds value, then if they want to offer that value > > to me as $ or £, I'd consider writing it if their total value was more > > than my cost > > > > Barry > > > > > ___ > > > R-devel@r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
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 be possible to take this one step further, and write an .exe builder, that automates the process of creating .exe files. Obviously, it would require a compiler and supporting libraries. I have a preference for GCC, and I'm not sure if you can run GCC on Windows without Cygwin. I may (or may not) look into this further, in a few weeks time. On Sun, Feb 3, 2019 at 2:27 AM Barry Rowlingson < b.rowling...@lancaster.ac.uk> 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 itself, its not in a repo), > install dependencies, and run the main() function. > > Now, I could build a self-executable shar file that bundled a package > together with a script to do all the above. But if there was a "RUN" > command in R, and a convention that a function called "foo::main" > would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much > easier to develop and test. > > If people think this adds value, then if they want to offer that value > to me as $ or £, I'd consider writing it if their total value was more > than my cost > > Barry > ___ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
remotes has fewer dependencies. I believe that the current version of devtools just re-exports install_github etc. from the remotes package. On 2019-02-02 11:31 a.m., David Lindelof wrote: > 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 remotes? > > Kind regards, > > From: Duncan Murdoch > Reply: Duncan Murdoch > Date: 2 February 2019 at 15:37:16 > To: Barry Rowlingson > , Abs Spurdle > > Cc: r-devel > Subject: Re: [Rd] Runnable R packages > > 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 itself, its not in a repo), >> install dependencies, and run the main() function. >> >> Now, I could build a self-executable shar file that bundled a package >> together with a script to do all the above. But if there was a "RUN" >> command in R, and a convention that a function called "foo::main" >> would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much >> easier to develop and test. > > I don't believe the "so much easier" argument that this requires a > change to base R. If you put that functionality into a package, then > the only extra effort the user would require is to install that other > package. After that, they could run > > Rscript -e "yourpackage::run_main('foo_1.1.1.tar.gz')" > > as I suggested before. This is no harder than running > > R CMD RUN foo_1.1.1.tar.gz > > The advantage of this from R Core's perspective is that you would be > developing and maintaining "yourpackage", you wouldn't be passing the > burden on to them. The advantage from your perspective is that you > could work with whatever packages you liked. The "remotes" package has > almost everything you need so that "yourpackage" could be nearly > trivial. You wouldn't need to duplicate it within base R. > > Duncan Murdoch > >> >> If people think this adds value, then if they want to offer that value >> to me as $ or £, I'd consider writing it if their total value was more >> than my cost >> >> Barry >> >> >> On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle wrote: >>> >>> 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]] >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > > David Lindelöf, Ph.D. > +41 (0)79 415 66 41 or skype:david.lindelof > http://computersandbuildings.com > Follow me on Twitter: > http://twitter.com/dlindelof > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
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 remotes? Kind regards, From: Duncan Murdoch Reply: Duncan Murdoch Date: 2 February 2019 at 15:37:16 To: Barry Rowlingson , Abs Spurdle Cc: r-devel Subject: Re: [Rd] Runnable R packages 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 itself, its not in a repo), > install dependencies, and run the main() function. > > Now, I could build a self-executable shar file that bundled a package > together with a script to do all the above. But if there was a "RUN" > command in R, and a convention that a function called "foo::main" > would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much > easier to develop and test. I don't believe the "so much easier" argument that this requires a change to base R. If you put that functionality into a package, then the only extra effort the user would require is to install that other package. After that, they could run Rscript -e "yourpackage::run_main('foo_1.1.1.tar.gz')" as I suggested before. This is no harder than running R CMD RUN foo_1.1.1.tar.gz The advantage of this from R Core's perspective is that you would be developing and maintaining "yourpackage", you wouldn't be passing the burden on to them. The advantage from your perspective is that you could work with whatever packages you liked. The "remotes" package has almost everything you need so that "yourpackage" could be nearly trivial. You wouldn't need to duplicate it within base R. Duncan Murdoch > > If people think this adds value, then if they want to offer that value > to me as $ or £, I'd consider writing it if their total value was more > than my cost > > Barry > > > On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle wrote: >> >> 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]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel David Lindelöf, Ph.D. +41 (0)79 415 66 41 or skype:david.lindelof http://computersandbuildings.com Follow me on Twitter: http://twitter.com/dlindelof [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
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 itself, its not in a repo), install dependencies, and run the main() function. Now, I could build a self-executable shar file that bundled a package together with a script to do all the above. But if there was a "RUN" command in R, and a convention that a function called "foo::main" would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much easier to develop and test. I don't believe the "so much easier" argument that this requires a change to base R. If you put that functionality into a package, then the only extra effort the user would require is to install that other package. After that, they could run Rscript -e "yourpackage::run_main('foo_1.1.1.tar.gz')" as I suggested before. This is no harder than running R CMD RUN foo_1.1.1.tar.gz The advantage of this from R Core's perspective is that you would be developing and maintaining "yourpackage", you wouldn't be passing the burden on to them. The advantage from your perspective is that you could work with whatever packages you liked. The "remotes" package has almost everything you need so that "yourpackage" could be nearly trivial. You wouldn't need to duplicate it within base R. Duncan Murdoch If people think this adds value, then if they want to offer that value to me as $ or £, I'd consider writing it if their total value was more than my cost Barry On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle wrote: 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]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
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 itself, its not in a repo), install dependencies, and run the main() function. Now, I could build a self-executable shar file that bundled a package together with a script to do all the above. But if there was a "RUN" command in R, and a convention that a function called "foo::main" would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much easier to develop and test. If people think this adds value, then if they want to offer that value to me as $ or £, I'd consider writing it if their total value was more than my cost Barry On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle wrote: > > 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]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
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]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
This is possibly the most redundant discussion I've ever seen on the R mailing lists. In the original post: > 2) It provides no way to deal with dependencies on other packages > 3) It provides no way to "run" an application provided as an R package Both completely false statements. > recently been a growing interest in developing full applications R was originally designed for interpreted use, with statistics and graphics. However, GUI, web and other applications are possible. And it's been around for a while. (So, not "recently"). Maybe your organization could/should pay a programmer to do it? [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
On 1 February 2019 at 13:31, William Dunlap via R-devel 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")' Or one could use 'littler' and install some of its examples in the $PATH path (which I tend to do via softlinks to get updates easily). Then it is simply $ install.r purrr and there is also install2.r with docopt goodness and more options. These have been my preferred tools for many years at home and work, and they found their way through Rocker dockerfiles as well as install2.r was started by Carl for added features. | For corporate "production use" you probably want to set up your own | repository containing | fixed versions of packages instead of using CRAN. Then edd repos="..." to | the install.packages() | call. Of course you can put this into a package and somehow deal with the | bootstrapping issue. Absolutely. But what repo to source packages from is somewhat orthogonal to how to install from there. Also, thanks to Gergely, repos is now an argument to install2.r Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
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 containing fixed versions of packages instead of using CRAN. Then edd repos="..." to the install.packages() call. Of course you can put this into a package and somehow deal with the bootstrapping issue. Bill Dunlap TIBCO Software wdunlap tibco.com On Thu, Jan 31, 2019 at 8:04 AM David Lindelof wrote: > 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.rowling...@lancaster.ac.uk> wrote: > > > > > > > On Thu, Jan 31, 2019 at 3:14 PM David Lindelof > 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 boilerplate R package called "runme". I > > can install its dependencies and run its "main" function with: > > > > $ R CMD INSTALL runme_0.0.0.9000.tar.gz > > $ R -e 'runme::main()' > > > > No new R CMDs needed. Now my choice of "main" is arbitrary, whereas with > > python and java and C the entrypoint is more tightly specified (__name__ > == > > "__main__" in python, int main(..) in C and so on). But I don't think > > that's much of a problem. > > > > Does that not satisfy your requirements close enough? If you want it in > > one line then: > > > > R CMD INSTALL runme_0.0.0.9000.tar.gz && R -e 'runme::main()' > > > > will do the second if the first succeeds (Unix shells). > > > > You could write a script for $RHOME/bin/RUN which would be a two-liner > and > > that could mandate the use of "main" as an entry point. But good luck > > getting anything into base R. > > > > Barry > > > > > > > > > >> If we have this machinery available, we could even consider > >> reaching out to Spark (and other tech stacks) developers and make it > >> easier > >> to develop R applications for those platforms. > >> > >> > > > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
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 wrote: > > 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 > wrote: >> >> >> >> On Thu, Jan 31, 2019 at 3:14 PM David Lindelof 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 boilerplate R package called "runme". I can >> install its dependencies and run its "main" function with: >> >> $ R CMD INSTALL runme_0.0.0.9000.tar.gz >> $ R -e 'runme::main()' >> >> No new R CMDs needed. Now my choice of "main" is arbitrary, whereas with >> python and java and C the entrypoint is more tightly specified (__name__ == >> "__main__" in python, int main(..) in C and so on). But I don't think that's >> much of a problem. >> >> Does that not satisfy your requirements close enough? If you want it in one >> line then: >> >> R CMD INSTALL runme_0.0.0.9000.tar.gz && R -e 'runme::main()' >> >> will do the second if the first succeeds (Unix shells). >> >> You could write a script for $RHOME/bin/RUN which would be a two-liner and >> that could mandate the use of "main" as an entry point. But good luck >> getting anything into base R. >> >> Barry >> >> >> >>> >>> If we have this machinery available, we could even consider >>> reaching out to Spark (and other tech stacks) developers and make it easier >>> to develop R applications for those platforms. >>> >> >> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
@Barry I'm not sure your proposal would work, since `R CMD INSTALL` won't install a package's dependencies. Indeed it will fail with an error unless all the dependencies are met before calling it. Speaking of which, why doesn't R CMD INSTALL install a package's dependencies? Would it make sense to submit this as a desirable feature? Cheers, David On Thu, Jan 31, 2019 at 4:38 PM Barry Rowlingson < b.rowling...@lancaster.ac.uk> wrote: > > > On Thu, Jan 31, 2019 at 3:14 PM David Lindelof 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 boilerplate R package called "runme". I > can install its dependencies and run its "main" function with: > > $ R CMD INSTALL runme_0.0.0.9000.tar.gz > $ R -e 'runme::main()' > > No new R CMDs needed. Now my choice of "main" is arbitrary, whereas with > python and java and C the entrypoint is more tightly specified (__name__ == > "__main__" in python, int main(..) in C and so on). But I don't think > that's much of a problem. > > Does that not satisfy your requirements close enough? If you want it in > one line then: > > R CMD INSTALL runme_0.0.0.9000.tar.gz && R -e 'runme::main()' > > will do the second if the first succeeds (Unix shells). > > You could write a script for $RHOME/bin/RUN which would be a two-liner and > that could mandate the use of "main" as an entry point. But good luck > getting anything into base R. > > Barry > > > > >> If we have this machinery available, we could even consider >> reaching out to Spark (and other tech stacks) developers and make it >> easier >> to develop R applications for those platforms. >> >> > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
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.rowling...@lancaster.ac.uk> wrote: > > > On Thu, Jan 31, 2019 at 3:14 PM David Lindelof 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 boilerplate R package called "runme". I > can install its dependencies and run its "main" function with: > > $ R CMD INSTALL runme_0.0.0.9000.tar.gz > $ R -e 'runme::main()' > > No new R CMDs needed. Now my choice of "main" is arbitrary, whereas with > python and java and C the entrypoint is more tightly specified (__name__ == > "__main__" in python, int main(..) in C and so on). But I don't think > that's much of a problem. > > Does that not satisfy your requirements close enough? If you want it in > one line then: > > R CMD INSTALL runme_0.0.0.9000.tar.gz && R -e 'runme::main()' > > will do the second if the first succeeds (Unix shells). > > You could write a script for $RHOME/bin/RUN which would be a two-liner and > that could mandate the use of "main" as an entry point. But good luck > getting anything into base R. > > Barry > > > > >> If we have this machinery available, we could even consider >> reaching out to Spark (and other tech stacks) developers and make it >> easier >> to develop R applications for those platforms. >> >> > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
Quoting: "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." This kind of increase the scope of your idea. New command in R CMD to redirect to "main" is interesting idea. On the other hand it will impose limitation on user comparing to the way how you could do it now: Rscript -e 'mypkg::mymain("myparam")' (or littler, it should be shipped with R IMO). For production system one doesn't want to just "install its dependencies". First dependencies has to be mirrored and their version frozen. Then testing your package on that set of dependencies. Once successfully done then same set of packages should be used for production deployment. For those processes you might find tools4pkgs branch in base R useful (packages.dcf, mirror.packages functions), unfortunately not merged: https://github.com/wch/r-source/compare/tools4pkgs Jan Gorecki On Thu, Jan 31, 2019 at 9:08 PM Barry Rowlingson wrote: > > On Thu, Jan 31, 2019 at 3:14 PM David Lindelof 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 boilerplate R package called "runme". I can > install its dependencies and run its "main" function with: > > $ R CMD INSTALL runme_0.0.0.9000.tar.gz > $ R -e 'runme::main()' > > No new R CMDs needed. Now my choice of "main" is arbitrary, whereas with > python and java and C the entrypoint is more tightly specified (__name__ == > "__main__" in python, int main(..) in C and so on). But I don't think > that's much of a problem. > > Does that not satisfy your requirements close enough? If you want it in one > line then: > > R CMD INSTALL runme_0.0.0.9000.tar.gz && R -e 'runme::main()' > > will do the second if the first succeeds (Unix shells). > > You could write a script for $RHOME/bin/RUN which would be a two-liner and > that could mandate the use of "main" as an entry point. But good luck > getting anything into base R. > > Barry > > > > > > If we have this machinery available, we could even consider > > reaching out to Spark (and other tech stacks) developers and make it easier > > to develop R applications for those platforms. > > > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
On Thu, Jan 31, 2019 at 3:14 PM David Lindelof 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 boilerplate R package called "runme". I can install its dependencies and run its "main" function with: $ R CMD INSTALL runme_0.0.0.9000.tar.gz $ R -e 'runme::main()' No new R CMDs needed. Now my choice of "main" is arbitrary, whereas with python and java and C the entrypoint is more tightly specified (__name__ == "__main__" in python, int main(..) in C and so on). But I don't think that's much of a problem. Does that not satisfy your requirements close enough? If you want it in one line then: R CMD INSTALL runme_0.0.0.9000.tar.gz && R -e 'runme::main()' will do the second if the first succeeds (Unix shells). You could write a script for $RHOME/bin/RUN which would be a two-liner and that could mandate the use of "main" as an entry point. But good luck getting anything into base R. Barry > If we have this machinery available, we could even consider > reaching out to Spark (and other tech stacks) developers and make it easier > to develop R applications for those platforms. > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
On 31/01/2019 9:32 a.m., David Lindelof wrote: 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 Shiny. And it seems to me that Docker-like solutions will still need some "point of entry" for the R application, which will have to be Rscript or littler. In my first email, I observed that Rscript expects a single expression or a single script, which is probably why (in my experience) many data scientists tend to provide their code in a very limited number of files. Gergely disagreed, arguing to the contrary that data scientists are encouraged to provide their application as an R package called by a short script executed by Rscript. But this doesn't happen where I work for several reasons: - it implies installing your package on the production machine(s), including its dependencies, which must be done by hand - some machine learning platforms will simply not accept code provided as an R package - we have some "big data" use cases for which we need Spark; Spark can run R or Python code, but only when it is provided as a single file. (On the other hand, Spark can run applications provided as JAR files) 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. If we have this machinery available, we could even consider reaching out to Spark (and other tech stacks) developers and make it easier to develop R applications for those platforms. A candid comment from Dirk suggested that I should implement this myself, which I would be happy to do, provided this is the normal procedure. Or is there a more formal process I should follow? You can't implement it to run under R CMD, but it should be straightforward to put this in an R package, to be run by Rscript using something like Rscript -e "yourpackage::run_main('somepackage')" You can use the installation code from the `remotes` package, so run_main() could be a pretty simple function. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
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 Shiny. And it seems to me that Docker-like solutions will still need some "point of entry" for the R application, which will have to be Rscript or littler. In my first email, I observed that Rscript expects a single expression or a single script, which is probably why (in my experience) many data scientists tend to provide their code in a very limited number of files. Gergely disagreed, arguing to the contrary that data scientists are encouraged to provide their application as an R package called by a short script executed by Rscript. But this doesn't happen where I work for several reasons: - it implies installing your package on the production machine(s), including its dependencies, which must be done by hand - some machine learning platforms will simply not accept code provided as an R package - we have some "big data" use cases for which we need Spark; Spark can run R or Python code, but only when it is provided as a single file. (On the other hand, Spark can run applications provided as JAR files) 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. If we have this machinery available, we could even consider reaching out to Spark (and other tech stacks) developers and make it easier to develop R applications for those platforms. A candid comment from Dirk suggested that I should implement this myself, which I would be happy to do, provided this is the normal procedure. Or is there a more formal process I should follow? Kind regards, David Lindelöf [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
On Mon, 7 Jan 2019 at 22:09, Gergely Daróczi 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 Docker to be installed, but if that's a > problem, probably better to "ship" the app as a web application and > share a URL with the user, eg backed by shinyproxy.io If Docker is a problem, you can also try podman: same usage, compatible with Dockerfiles and daemon-less, no admin rights required. https://podman.io/ Iñaki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
On 7 January 2019 at 22:09, Gergely Daróczi wrote: | 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 Docker to be installed, but if that's a | problem, probably better to "ship" the app as a web application and | share a URL with the user, eg backed by shinyproxy.io Excellent suggestion. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
Some other major tech companies have in the past widely use Runnable R Archives (".Rar" files), similar to Python .par files [1], and integrate them completely into the proprietary R package build system in use there. I thought there were a few systems like this that had made their way to CRAN or the UseR conferences, but I don't have a link. Building something specific to your organization on top of the python .par framework to archive up R, your needed packages/shared libraries, and other dependencies with a runner script to R CMD RUN your entry point in a sandbox is pretty straightforward way to have control in a way that makes sense for your environment. - Murray [1] https://google.github.io/subpar/subpar.html On Mon, Jan 7, 2019 at 12:53 PM David Lindelof 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. > > 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 language. Three examples come to mind: > > 1) The Shiny web application framework, which facilitates the developent of > rich, interactive web applications > 2) The httr package, which provides lower-level facilities than Shiny for > writing web services > 3) Batch jobs run by data scientists according to, say, a cron schedule > > Compared with other languages, R’s support for such applications is rather > poor. The Rscript program is generally used to run an R script or an > arbitrary R expression, but I feel it suffers from a few problems: > > 1) It encourages developers of batch jobs to provide their code in a single > R file (bad for code structure and unit-testability) > 2) It provides no way to deal with dependencies on other packages > 3) It provides no way to "run" an application provided as an R package > > For example, let’s say I want to run a Shiny application that I provide as > an R package (to keep the code modular, to benefit from unit tests, and to > declare dependencies properly). I would then need to a) uncompress my R > package, b) somehow, ensure my dependencies are installed, and c) call > runApp(). This can get tedious, fast. > > Other languages let the developer package their code in "runnable" > artefacts, and let the developer specify the main entry point. The > mechanics depend on the language but are remarkably similar, and suggest a > way to implement this in R. Through declarations in some file, the > developer can often specify dependencies and declare where the program’s > "main" function resides. Consider Java: > > Artefact: .jar file > Declarations file: Manifest file > Entry point: declared as 'Main-Class' > Executed as: java -jar > > Or Python: > > Artefact: Python package, typically as .tar.gz source distribution file > Declarations file: setup.py (which specifies dependencies) > Entry point: special __main__() function > Executed as: python -m > > R has already much of this machinery: > > Artefact: R package > Declarations file: DESCRIPTION > Entry point: ? > Executed as: ? > > I feel that R could benefit from letting the developer specify, possibly in > DESCRIPTION, how to "run" the package. The package could then be run > through, for example, a new R CMD command, for example: > > R CMD RUN > > I’m sure there are plenty of wrinkles in this idea that need to be ironed > out, but is this something that has ever been considered, or that is on R’s > roadmap? > > Thanks for reading so far, > > > > David Lindelöf, Ph.D. > +41 (0)79 415 66 41 or skype:david.lindelof > http://computersandbuildings.com > Follow me on Twitter: > http://twitter.com/dlindelof > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
On 3 January 2019 at 11:43, David Lindelof 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. | | 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 language. Three examples come to mind: | | 1) The Shiny web application framework, which facilitates the developent of | rich, interactive web applications | 2) The httr package, which provides lower-level facilities than Shiny for | writing web services | 3) Batch jobs run by data scientists according to, say, a cron schedule That is a bit of a weird classification of "full applications". I have done this about as long as you but I also provided (at least as tests and demos) i) GUI apps using tcl/tk (which comes with R) and ii) GUI apps with Qt (or even Wt), see my RInside package. But my main weapon for 3) is littler. See https://cran.r-project.org/package=littler and particularly the many examples at https://github.com/eddelbuettel/littler/tree/master/inst/examples | Compared with other languages, R’s support for such applications is rather | poor. The Rscript program is generally used to run an R script or an | arbitrary R expression, but I feel it suffers from a few problems: | | 1) It encourages developers of batch jobs to provide their code in a single | R file (bad for code structure and unit-testability) | 2) It provides no way to deal with dependencies on other packages | 3) It provides no way to "run" an application provided as an R package Err, no. See the examples/ directory above. About every single one uses packages. As illustrations I have long-running and somewhat visible cronjobs that are implemented the same way: CRANberries (since 2007, now running hourly) and CRAN Policy Watch (running once a day). Because both are 'hacks' I never published the code but there is not that much to it. CRANberries just queries CRAN, compares to what it had last, and writes out variants of the DESCRIPTION file to text where a static blog engine (like Hugo, but older) makes a feed and html pagaes out of it. Oh, and we tweet because "why not?". | For example, let’s say I want to run a Shiny application that I provide as | an R package (to keep the code modular, to benefit from unit tests, and to | declare dependencies properly). I would then need to a) uncompress my R | package, b) somehow, ensure my dependencies are installed, and c) call | runApp(). This can get tedious, fast. Disagree here too. At work, I just write my code, organize it in packages, update the packages and have shiny expose whatever makes sense. | Other languages let the developer package their code in "runnable" | artefacts, and let the developer specify the main entry point. The | mechanics depend on the language but are remarkably similar, and suggest a | way to implement this in R. Through declarations in some file, the | developer can often specify dependencies and declare where the program’s | "main" function resides. Consider Java: | | Artefact: .jar file | Declarations file: Manifest file | Entry point: declared as 'Main-Class' | Executed as: java -jar | | Or Python: | | Artefact: Python package, typically as .tar.gz source distribution file | Declarations file: setup.py (which specifies dependencies) | Entry point: special __main__() function | Executed as: python -m | | R has already much of this machinery: | | Artefact: R package | Declarations file: DESCRIPTION | Entry point: ? | Executed as: ? | | I feel that R could benefit from letting the developer specify, possibly in | DESCRIPTION, how to "run" the package. The package could then be run | through, for example, a new R CMD command, for example: | | R CMD RUN | | I’m sure there are plenty of wrinkles in this idea that need to be ironed | out, but is this something that has ever been considered, or that is on R’s | roadmap? Hm. If _you_ have an itch to scratch here why don't _you_ implement a draft. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
Dear David, sharing some related (subjective) thoughts below. On Mon, Jan 7, 2019 at 9:53 PM David Lindelof 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. > > 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 language. Three examples come to mind: > > 1) The Shiny web application framework, which facilitates the developent of > rich, interactive web applications > 2) The httr package, which provides lower-level facilities than Shiny for > writing web services > 3) Batch jobs run by data scientists according to, say, a cron schedule > > Compared with other languages, R’s support for such applications is rather > poor. The Rscript program is generally used to run an R script or an > arbitrary R expression, but I feel it suffers from a few problems: > > 1) It encourages developers of batch jobs to provide their code in a single > R file (bad for code structure and unit-testability) I think it rather encourages developers to create (internal) R packages and use those from the batch jobs. This way the structure is pretty clean, sharing code between scripts is easy, unit testing can be done within the package etc. > 2) It provides no way to deal with dependencies on other packages See above: create R package(s) and use those from the scripts. > 3) It provides no way to "run" an application provided as an R package > > For example, let’s say I want to run a Shiny application that I provide as > an R package (to keep the code modular, to benefit from unit tests, and to > declare dependencies properly). I would then need to a) uncompress my R > package, b) somehow, ensure my dependencies are installed, and c) call > runApp(). This can get tedious, fast. 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 Docker to be installed, but if that's a problem, probably better to "ship" the app as a web application and share a URL with the user, eg backed by shinyproxy.io > > Other languages let the developer package their code in "runnable" > artefacts, and let the developer specify the main entry point. The > mechanics depend on the language but are remarkably similar, and suggest a > way to implement this in R. Through declarations in some file, the > developer can often specify dependencies and declare where the program’s > "main" function resides. Consider Java: > > Artefact: .jar file > Declarations file: Manifest file > Entry point: declared as 'Main-Class' > Executed as: java -jar > > Or Python: > > Artefact: Python package, typically as .tar.gz source distribution file > Declarations file: setup.py (which specifies dependencies) > Entry point: special __main__() function > Executed as: python -m > > R has already much of this machinery: > > Artefact: R package > Declarations file: DESCRIPTION > Entry point: ? > Executed as: ? > > I feel that R could benefit from letting the developer specify, possibly in > DESCRIPTION, how to "run" the package. The package could then be run > through, for example, a new R CMD command, for example: > > R CMD RUN > > I’m sure there are plenty of wrinkles in this idea that need to be ironed > out, but is this something that has ever been considered, or that is on R’s > roadmap? > > Thanks for reading so far, > > > > David Lindelöf, Ph.D. > +41 (0)79 415 66 41 or skype:david.lindelof > http://computersandbuildings.com > Follow me on Twitter: > http://twitter.com/dlindelof > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Runnable R packages
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 language. Three examples come to mind: 1) The Shiny web application framework, which facilitates the developent of rich, interactive web applications 2) The httr package, which provides lower-level facilities than Shiny for writing web services 3) Batch jobs run by data scientists according to, say, a cron schedule Compared with other languages, R’s support for such applications is rather poor. The Rscript program is generally used to run an R script or an arbitrary R expression, but I feel it suffers from a few problems: 1) It encourages developers of batch jobs to provide their code in a single R file (bad for code structure and unit-testability) 2) It provides no way to deal with dependencies on other packages 3) It provides no way to "run" an application provided as an R package For example, let’s say I want to run a Shiny application that I provide as an R package (to keep the code modular, to benefit from unit tests, and to declare dependencies properly). I would then need to a) uncompress my R package, b) somehow, ensure my dependencies are installed, and c) call runApp(). This can get tedious, fast. Other languages let the developer package their code in "runnable" artefacts, and let the developer specify the main entry point. The mechanics depend on the language but are remarkably similar, and suggest a way to implement this in R. Through declarations in some file, the developer can often specify dependencies and declare where the program’s "main" function resides. Consider Java: Artefact: .jar file Declarations file: Manifest file Entry point: declared as 'Main-Class' Executed as: java -jar Or Python: Artefact: Python package, typically as .tar.gz source distribution file Declarations file: setup.py (which specifies dependencies) Entry point: special __main__() function Executed as: python -m R has already much of this machinery: Artefact: R package Declarations file: DESCRIPTION Entry point: ? Executed as: ? I feel that R could benefit from letting the developer specify, possibly in DESCRIPTION, how to "run" the package. The package could then be run through, for example, a new R CMD command, for example: R CMD RUN I’m sure there are plenty of wrinkles in this idea that need to be ironed out, but is this something that has ever been considered, or that is on R’s roadmap? Thanks for reading so far, David Lindelöf, Ph.D. +41 (0)79 415 66 41 or skype:david.lindelof http://computersandbuildings.com Follow me on Twitter: http://twitter.com/dlindelof [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel