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 <murdoch.duncan at
gmail.com>
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 <spurdle.a at
gmail.com> 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 at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
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 "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 <murdoch.duncan at gmail.com> > 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 <spurdle.a at gmail.com> 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 at r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at 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.Krug at uzh.ch Rainer at krugs.de Skype: RMkrug PGP: 0x0F52F982 [[alternative HTML version deleted]]
Sure, you can find it here: https://github.com/dlindelof/run On Fri, Feb 8, 2019 at 9:41 AM Rainer M Krug <Rainer at krugs.de> wrote:> 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 "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 <murdoch.duncan at gmail.com> > 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 <spurdle.a at gmail.com> 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 at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at 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.Krug at uzh.ch <Rainer.Krug at uzh.ch> > Rainer at krugs.de > Skype: RMkrug > > PGP: 0x0F52F982 > > > >[[alternative HTML version deleted]]