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?
[R-pkg-devel] How to link executables for non-R-users?
3 messages · Michael Cysouw, Duncan Murdoch, Dirk Eddelbuettel
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
On 16 June 2016 at 15:56, 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> Exactly what is missing in the (wonderful, in my book) docopt package, and could you file an issue ticket at the corresponding GitHub repo, please? FWIW it 'works for me' eg here https://github.com/eddelbuettel/littler/blob/master/inst/examples/install2.r (and also on CRAN in this 'littler' package). | 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. There is no bash interface. Just write scripts for '#!/usr/bin/env Rscript' or (my preference) '#!/usr/bin/env r' (or use the path directly). R is perfectly well suited for shebang scripting. | 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? We do this at work *a lot* and generally place them into inst/scripts/ and then have a _one-time_ need for a soft-link from /usr/local/bin/ into the packages' scripts/ directory. | 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? You would need to convince R Core to let you run post-install hooks. AFAICR only one or two packages do this; Simon's Rserve I think gets allows into R's bin/ directory. | 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 Why do you think you need bash? It makes your approach less portable (as Windoze generally does not have it). Other systems have other shells, sometimes a lot smaller than bash. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org