[Rd] Runnable R packages

Barry Rowlingson b@row||ng@on @end|ng |rom |@nc@@ter@@c@uk
Fri Feb 1 21:19:54 CET 2019


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 using ieee.org> 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.rowlingson using lancaster.ac.uk> wrote:
>>
>>
>>
>> On Thu, Jan 31, 2019 at 3:14 PM David Lindelof <lindelof using 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 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.
>>>
>>
>>



More information about the R-devel mailing list