Runnable R packages

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Runnable R packages

bbolker

  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 <[hidden email]> <[hidden email]>
> Reply: Duncan Murdoch <[hidden email]> <[hidden email]>
> Date: 2 February 2019 at 15:37:16
> To: Barry Rowlingson <[hidden email]>
> <[hidden email]>, Abs Spurdle <[hidden email]>
> <[hidden email]>
> Cc: r-devel <[hidden email]> <[hidden email]>
> 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 <[hidden email]> 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]]
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> [hidden email] 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]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Runnable R packages

Abby Spurdle
In reply to this post by barry rowlingson
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 <
[hidden email]> 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
>


___________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Runnable R packages

Peter Meissner-3
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 <[hidden email]>:

> 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 <
> [hidden email]> 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
> >
>
>
> ___________________________________________
> > > [hidden email] mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Runnable R packages

David Lindelof-3
In reply to this post by Duncan Murdoch-2
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 <[hidden email]>
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 <[hidden email]> 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]]
> >>
> >> ______________________________________________
> >> [hidden email] mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Runnable R packages

Rainer Krug-3
Sounds interesting. Do you have it on GitHub or similar?

Rainer

> On 8 Feb 2019, at 09:09, David Lindelof <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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]]
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] 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:      [hidden email]
                [hidden email]
Skype:     RMkrug

PGP: 0x0F52F982




        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Runnable R packages

David Lindelof-3
Sure, you can find it here:

https://github.com/dlindelof/run


On Fri, Feb 8, 2019 at 9:41 AM Rainer M Krug <[hidden email]> wrote:

> Sounds interesting. Do you have it on GitHub or similar?
>
> Rainer
>
> On 8 Feb 2019, at 09:09, David Lindelof <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] 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:      [hidden email] <[hidden email]>
> [hidden email]
> Skype:     RMkrug
>
> PGP: 0x0F52F982
>
>
>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Runnable R packages

Abby Spurdle
In reply to this post by Peter Meissner-3
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 <[hidden email]>
wrote:

> Doesn't Rtools provide everything needed to build R packages and R on
> Windows - including gcc?
>
>>
>>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
12