[Rd] Runnable R packages

[David Lindelof]

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 <murdoch.duncan using gmail.com> <murdoch.duncan using gmail.com>
Reply: Duncan Murdoch <murdoch.duncan using gmail.com> <murdoch.duncan using gmail.com>
Date: 2 February 2019 at 15:37:16
To: Barry Rowlingson <b.rowlingson using lancaster.ac.uk>
<b.rowlingson using lancaster.ac.uk>, Abs Spurdle <spurdle.a using gmail.com>
<spurdle.a using gmail.com>
Cc: r-devel <r-devel using r-project.org> <r-devel using r-project.org>
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 <spurdle.a using 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 using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
R-devel using r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


David Lindelöf, Ph.D.
+41 (0)79 415 66 41 <//415 66 41> or skype:david.lindelof
http://computersandbuildings.com
Follow me on Twitter:
http://twitter.com/dlindelof

	[[alternative HTML version deleted]]