An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20131030/3f052879/attachment.pl>
Where to drop a python script?
8 messages · Jonathan Greenberg, Marc Schwartz, Dirk Eddelbuettel +2 more
On Oct 30, 2013, at 1:54 PM, Jonathan Greenberg <jgrn at illinois.edu> wrote:
R-developers: I have a small python script that I'd like to include in an R package I'm developing, but I'm a bit unclear about which subfolder it should go in. R will be calling the script via a system() call. Thanks! --j
See Writing R Extensions Manual, section 1.1.7: http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Non_002dR-scripts-in-packages If you want to see a package example, my WriteXLS package uses Perl, but the concepts will be the same: https://github.com/marcschwartz/WriteXLS If you look at WriteXLS.R around line 130, you can see an example of getting the $PATH to the included Perl scripts that I use, which are in the 'inst/Perl' folder. Further down around line 230, is where the script is called via system(). Note the use of shQuote() for some arguments. Regards, Marc Schwartz
On 30 October 2013 at 13:54, Jonathan Greenberg wrote:
| R-developers: | | I have a small python script that I'd like to include in an R package I'm | developing, but I'm a bit unclear about which subfolder it should go in. R | will be calling the script via a system() call. Thanks! Up to you as you control the path. As "Writing R Extensions" explains, everything below the (source) directory inst/ will get installed. I like inst/extScripts/ (or similar) as it denotes that it is an external script. As an example, the gdata package has Perl code for xls reading/writing below a directory inst/perl/ -- and I think there are more packages doing this. Dirk
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
The old convention was that it went in the exec/ directory, but as you can see at http://cran.at.r-project.org/doc/manuals/r-devel/R-exts.html#Non_002dR-scripts-in-packages it can be in inst/anyName/. A minor convenience of exec/ is that the directory has the same name in source and when installed, whereas inst/anyName gets moved to anyName/, so debugging can be a tiny bit easier with exec/. Having just put a package (TSjson) on CRAN with a python script, here are a few other pointers for getting it on CRAN: -SystemRequirements: should indicate if a particular version of python is needed, and any non-default modules that are needed. (My package does not work with Python 3 because some modules are not available.) Some of the libraries have changed, so it could be a bit tricky to make something work easily with both 2 and 3. -You need a README to explain how to install Python. (If you look at or use mine, please let me know if you find problems.) -The Linux and Sun CRAN test machines have Python 2 whereas winbuilder has Python 3. Be prepared to explain that the package will not work on one or the other. Another option to system() is pipe() Paul
On 13-10-30 03:15 PM, Dirk Eddelbuettel wrote:
On 30 October 2013 at 13:54, Jonathan Greenberg wrote: | R-developers: | | I have a small python script that I'd like to include in an R package I'm | developing, but I'm a bit unclear about which subfolder it should go in. R | will be calling the script via a system() call. Thanks! Up to you as you control the path. As "Writing R Extensions" explains, everything below the (source) directory inst/ will get installed. I like inst/extScripts/ (or similar) as it denotes that it is an external script. As an example, the gdata package has Perl code for xls reading/writing below a directory inst/perl/ -- and I think there are more packages doing this. Dirk
On 31/10/2013 00:40, Paul Gilbert wrote:
The old convention was that it went in the exec/ directory, but as you can see at http://cran.at.r-project.org/doc/manuals/r-devel/R-exts.html#Non_002dR-scripts-in-packages it can be in inst/anyName/. A minor convenience of exec/ is that the directory has the same name in source and when installed, whereas inst/anyName gets moved to anyName/, so debugging can be a tiny bit easier with exec/. Having just put a package (TSjson) on CRAN with a python script, here are a few other pointers for getting it on CRAN: -SystemRequirements: should indicate if a particular version of python is needed, and any non-default modules that are needed. (My package does not work with Python 3 because some modules are not available.) Some of the libraries have changed, so it could be a bit tricky to make something work easily with both 2 and 3. -You need a README to explain how to install Python. (If you look at or use mine, please let me know if you find problems.)
Better to describe exactly what you need: installation instructions go stale very easily.
-The Linux and Sun CRAN test machines have Python 2 whereas winbuilder has Python 3. Be prepared to explain that the package will not work on one or the other.
Not true. Linux and Solaris (sic) have both: the Solaris machines have 2.6 and 3.3. Please do not spread misinformation about machines you do not have any access to.
Another option to system() is pipe() Paul On 13-10-30 03:15 PM, Dirk Eddelbuettel wrote:
On 30 October 2013 at 13:54, Jonathan Greenberg wrote: | R-developers: | | I have a small python script that I'd like to include in an R package I'm | developing, but I'm a bit unclear about which subfolder it should go in. R | will be calling the script via a system() call. Thanks! Up to you as you control the path. As "Writing R Extensions" explains, everything below the (source) directory inst/ will get installed. I like inst/extScripts/ (or similar) as it denotes that it is an external script. As an example, the gdata package has Perl code for xls reading/writing below a directory inst/perl/ -- and I think there are more packages doing this. Dirk
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
On 13-10-31 03:01 AM, Prof Brian Ripley wrote:
On 31/10/2013 00:40, Paul Gilbert wrote:
The old convention was that it went in the exec/ directory, but as you can see at http://cran.at.r-project.org/doc/manuals/r-devel/R-exts.html#Non_002dR-scripts-in-packages it can be in inst/anyName/. A minor convenience of exec/ is that the directory has the same name in source and when installed, whereas inst/anyName gets moved to anyName/, so debugging can be a tiny bit easier with exec/. Having just put a package (TSjson) on CRAN with a python script, here are a few other pointers for getting it on CRAN: -SystemRequirements: should indicate if a particular version of python is needed, and any non-default modules that are needed. (My package does not work with Python 3 because some modules are not available.) Some of the libraries have changed, so it could be a bit tricky to make something work easily with both 2 and 3. -You need a README to explain how to install Python. (If you look at or use mine, please let me know if you find problems.)
Better to describe exactly what you need: installation instructions go stale very easily.
-The Linux and Sun CRAN test machines have Python 2 whereas winbuilder has Python 3. Be prepared to explain that the package will not work on one or the other.
Not true. Linux and Solaris (sic) have both: the Solaris machines have 2.6 and 3.3.
For an R package how does one go about specifying which should be used?
Please do not spread misinformation about machines you do not have any access to.
Another option to system() is pipe() Paul On 13-10-30 03:15 PM, Dirk Eddelbuettel wrote:
On 30 October 2013 at 13:54, Jonathan Greenberg wrote: | R-developers: | | I have a small python script that I'd like to include in an R package I'm | developing, but I'm a bit unclear about which subfolder it should go in. R | will be calling the script via a system() call. Thanks! Up to you as you control the path. As "Writing R Extensions" explains, everything below the (source) directory inst/ will get installed. I like inst/extScripts/ (or similar) as it denotes that it is an external script. As an example, the gdata package has Perl code for xls reading/writing below a directory inst/perl/ -- and I think there are more packages doing this. Dirk
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On 31/10/2013 15:33, Paul Gilbert wrote:
On 13-10-31 03:01 AM, Prof Brian Ripley wrote:
On 31/10/2013 00:40, Paul Gilbert wrote:
The old convention was that it went in the exec/ directory, but as you can see at http://cran.at.r-project.org/doc/manuals/r-devel/R-exts.html#Non_002dR-scripts-in-packages it can be in inst/anyName/. A minor convenience of exec/ is that the directory has the same name in source and when installed, whereas inst/anyName gets moved to anyName/, so debugging can be a tiny bit easier with exec/. Having just put a package (TSjson) on CRAN with a python script, here are a few other pointers for getting it on CRAN: -SystemRequirements: should indicate if a particular version of python is needed, and any non-default modules that are needed. (My package does not work with Python 3 because some modules are not available.) Some of the libraries have changed, so it could be a bit tricky to make something work easily with both 2 and 3. -You need a README to explain how to install Python. (If you look at or use mine, please let me know if you find problems.)
Better to describe exactly what you need: installation instructions go stale very easily.
-The Linux and Sun CRAN test machines have Python 2 whereas winbuilder has Python 3. Be prepared to explain that the package will not work on one or the other.
Not true. Linux and Solaris (sic) have both: the Solaris machines have 2.6 and 3.3.
For an R package how does one go about specifying which should be used?
You ask the user to tell you the path or at least the command name, e.g. by an environment variable or R function argument. Just like any other external program such as GhostScript.
Please do not spread misinformation about machines you do not have any access to.
Another option to system() is pipe() Paul On 13-10-30 03:15 PM, Dirk Eddelbuettel wrote:
On 30 October 2013 at 13:54, Jonathan Greenberg wrote: | R-developers: | | I have a small python script that I'd like to include in an R package I'm | developing, but I'm a bit unclear about which subfolder it should go in. R | will be calling the script via a system() call. Thanks! Up to you as you control the path. As "Writing R Extensions" explains, everything below the (source) directory inst/ will get installed. I like inst/extScripts/ (or similar) as it denotes that it is an external script. As an example, the gdata package has Perl code for xls reading/writing below a directory inst/perl/ -- and I think there are more packages doing this. Dirk
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
On 13-10-31 01:16 PM, Prof Brian Ripley wrote:
On 31/10/2013 15:33, Paul Gilbert wrote:
On 13-10-31 03:01 AM, Prof Brian Ripley wrote:
On 31/10/2013 00:40, Paul Gilbert wrote:
The old convention was that it went in the exec/ directory, but as you can see at http://cran.at.r-project.org/doc/manuals/r-devel/R-exts.html#Non_002dR-scripts-in-packages it can be in inst/anyName/. A minor convenience of exec/ is that the directory has the same name in source and when installed, whereas inst/anyName gets moved to anyName/, so debugging can be a tiny bit easier with exec/. Having just put a package (TSjson) on CRAN with a python script, here are a few other pointers for getting it on CRAN: -SystemRequirements: should indicate if a particular version of python is needed, and any non-default modules that are needed. (My package does not work with Python 3 because some modules are not available.) Some of the libraries have changed, so it could be a bit tricky to make something work easily with both 2 and 3. -You need a README to explain how to install Python. (If you look at or use mine, please let me know if you find problems.)
Better to describe exactly what you need: installation instructions go stale very easily.
-The Linux and Sun CRAN test machines have Python 2 whereas winbuilder has Python 3. Be prepared to explain that the package will not work on one or the other.
Not true. Linux and Solaris (sic) have both: the Solaris machines have 2.6 and 3.3.
For an R package how does one go about specifying which should be used?
You ask the user to tell you the path or at least the command name, e.g. by an environment variable or R function argument. Just like any other external program such as GhostScript.
Yes, but since I don't have direct access to the CRAN test machines, specifically, on the CRAN test machines, how do I specify to use Python 2 or Python 3? (That is, I think you are the user when CRAN tests are done on Solaris, so I am asking you.)
Please do not spread misinformation about machines you do not have any access to.
Another option to system() is pipe() Paul On 13-10-30 03:15 PM, Dirk Eddelbuettel wrote:
On 30 October 2013 at 13:54, Jonathan Greenberg wrote: | R-developers: | | I have a small python script that I'd like to include in an R package I'm | developing, but I'm a bit unclear about which subfolder it should go in. R | will be calling the script via a system() call. Thanks! Up to you as you control the path. As "Writing R Extensions" explains, everything below the (source) directory inst/ will get installed. I like inst/extScripts/ (or similar) as it denotes that it is an external script. As an example, the gdata package has Perl code for xls reading/writing below a directory inst/perl/ -- and I think there are more packages doing this. Dirk
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel