[R-pkg-devel] How to link executables for non-R-users?

Duncan Murdoch murdoch.duncan at gmail.com
Thu Jun 16 16:24:01 CEST 2016

On 16/06/2016 9:56 AM, Michael Cysouw wrote:
> I really like the possibility of projects like docopt <http://docopt.org>, providing a bash interface to R functionality. IMHO this is a great way to allow non-R-users to include R functionality in their workflows. There is a docopt package for R which is not yet perfect for my liking, but already goes a long way. <https://cran.r-project.org/web/packages/docopt/index.html>
> I have been experimenting a bit with including docopt scripts into my R packages, and I would like to ask for some feedback how to handle the distribution of such bash-interfaces with R packages.
> Ideally, such bash-interfaces like docopt should be distributed together with the R packages, and the “exec” folder seems destined for that goal. Simply adding the package docopt as a requirement in DESCRIPTION also assures that everything just works after installing the package!
> The main remaining problem is the following: How do non-R-users actually find the bash-executable? The location is rather hidden away :-). Is there a way to link the path to the exec folder to PATH on installing a package? Or is there an easy way to allow people to make an alias in their .bashrc?

Just put a description of what to do into your vignette.
>  From within R this is not that difficult, using something based on “find.package”:
> `file.path(find.package(package_name), "exec", docopt_file_name)`
> However, I am more thinking about an option for R CMD INSTALL to link an executable to PATH. Would that be sensible? How should that be done?

I don't think packages should be messing with users' PATHs. Document 
what is necessary, even provide functions in your package to do the 
work, but don't do it automatically.  I think you were suggesting 
something optional, but I really see no point in that: it is no more 
work for you to write a function to do the work than it would be for you 
to handle a request from INSTALL to do the work, but it is a lot more 
work for us.

Duncan Murdoch
> Further note that to prevent clogging the PATH with executable, I would propose that package developers only include a single bash-interface to a package, named identically to the package, with multiple functions available as (sub)commands, so a bash user could simply access a function “bla” from package “foo” as
> $ foo bla -OPTIONS [ARGUMENTS]
> thanks for any feedback
> michael
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

More information about the R-package-devel mailing list