[Rd] Conditional importFrom (roxygen?)

[Jonathan Greenberg]

Folks:

I am getting a build failure when I:
#' @importFrom utils shortPathName

which roxygenizes it to the NAMESPACE.

I suspect this is because this particular function is Windows-only, but I'm
a bit confused how I should "properly" importFrom a function like this so
it doesn't cause a build failure, but I don't get a note in my R CMD CHECK
if I DON'T have it:

gdal_setInstallation : correctPath: no visible global function
  definition for 'shortPathName'
gdalinfo: no visible global function definition for 'glob2rx'
gdallocationinfo: no visible global function definition for
  'write.table'
gdaltransform: no visible global function definition for 'write.table'
get_subdatasets: no visible global function definition for 'glob2rx'
mosaic_rasters: no visible global function definition for 'write.table'
Undefined global functions or variables:
  glob2rx shortPathName write.table
Consider adding
  importFrom("utils", "glob2rx", "shortPathName", "write.table")
to your NAMESPACE.

I'll note my function actually first checks to see what OS is running, and
doesn't use this function on non-Windows machines, so having this function
does not cause any actual errors:

...

if (.Platform$OS.type=="windows")

{

x <- shortPathName(x)

} else

{

x <- path.expand(x)

}


...

Is there a way to do a conditional importFrom based on the OS?  Or can I
safely ignore this (I'm trying to submit to CRAN).

--j

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] library() in .Rd Examples (Depends vs. Imports)?

[Jonathan Greenberg]

I'm a little confused when documenting my code using Imports vs. Depends.
If I have an example in my .Rd that uses a library that is listed under
Imports, it doesn't work, but if it is listed under Depends, it does.  What
is the proper way to go about using examples that rely on an Imports?
Should I just if(require(somepackage)) in the example?  Or is there a more
elegant way of doing this?

--j

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Policy/best practices on renaming functions in packages

[Jonathan Greenberg]

R-developers:

I'm beginning to work on a manuscript for a set of functions I
developed for a package I have on CRAN (spatial.tools), and I'd like
to rename a function in my package to give a better idea of what it
does prior to manuscript submission -- is there a "safe" way to do a
backwards-compatible rename of a function within a CRAN package (so
functions that rely on the original name aren't broken)?  Is it as
simple as:

new_name <- old_name <- function(yadda)
{

}

In general, I'd just leave it as is, but the old name of the function
was a reference to an existing function in another package that it no
longer has any resemblance to.

Thanks!

--j

--
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
607 South Mathews Avenue, MC 150
Urbana, IL 61801
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] "Proper" way to use a "hidden" function in an R-package?

[Jonathan Greenberg]

R-developers:

I'm working on updating my R package "spatial.tools", and one thing I
was wondering was the proper way to have hidden functions -- should I
simply not export them to the namespace and use the ::: operator to
call them (which is what I currently do)?

--j

--
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
607 South Mathews Avenue, MC 150
Urbana, IL 61801
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] "Proper" way to use a "hidden" function in an R-package?

[Jonathan Greenberg]

I think part of this may be my (possibly flawed) understanding of
documentation requirements for CRAN -- if a function is exported to
the namespace, does CRAN require documentation of that function?  The
reason I ask is that I have a lot of these little functions that have
no need for documentation (since they are only used internally by a
larger, documented function -- no end-user would touch them).  If this
is flawed understanding, do I just export it to the NAMESPACE and I'm
good to go?

--j

On Fri, Jul 12, 2013 at 11:35 AM, Duncan Murdoch
 wrote:
> On 13-07-12 5:52 PM, Jonathan Greenberg wrote:
>> R-developers:
>>
>> I'm working on updating my R package "spatial.tools", and one thing I
>> was wondering was the proper way to have hidden functions -- should I
>> simply not export them to the namespace and use the ::: operator to
>> call them (which is what I currently do)?
>
> Are you calling them from inside the package?  If so, you don't need the
> :::.
>
> If you're not calling them from inside the package, then why not export
> them?  I think you need to explain the context.
>
> Duncan Murdoch
>
>>
>> --j
>>
>> --
>> Jonathan A. Greenberg, PhD
>> Assistant Professor
>> Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
>> Department of Geography and Geographic Information Science
>> University of Illinois at Urbana-Champaign
>> 607 South Mathews Avenue, MC 150
>> Urbana, IL 61801
>> Phone: 217-300-1924
>> http://www.geog.illinois.edu/~jgrn/
>> AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>



-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
607 South Mathews Avenue, MC 150
Urbana, IL 61801
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Minimum requirements for package submission

[Jonathan Greenberg]

I had a similar question awhile ago.  Basically, my understanding is
if it is a function, it needs to be documented UNLESS you are calling
it via :::

--j

On Thu, Aug 29, 2013 at 1:11 PM, Sana Wajid  wrote:
> Thank you all, I appreciate your responses. Just a quick follow up
> question: couple of my functions are "background" or "behind the scenes"
> functions. Do these have to be documented in the manual as well?
>
>
> On Wed, Aug 28, 2013 at 5:19 PM, Geoff Jentry wrote:
>
>> On Wed, 28 Aug 2013, Ben Bolker wrote:
>>
>>>  It may be suboptimal/there may be better ways, but what I would do in
>>> your situation would be to save the real twitteR results to a .Rdata file
>>> (e.g. put it in inst/vignetteData) and then 'fake' the twitter call: add a
>>> non-eval'd but echo'd chunk that appears to run the command, and an eval'd
>>> but non-echo'd chunk that loads the results of having run the command.
>>>
>>
>> Interesting, I'll look into doing that.
>>
>> Thanks
>> -J
>>
>>
>> __**
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/**listinfo/r-devel
>>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
607 South Mathews Avenue, MC 150
Urbana, IL 61801
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Minimum requirements for package submission

[Jonathan Greenberg]

Ah, sorry -- I thought if I try to call a "hidden" function that has
not be exported (and, I thought, if it is exported, it needs to be
documented?), I have to call it via ::: ?

--j

On Thu, Aug 29, 2013 at 2:33 PM, Hadley Wickham  wrote:
> You only need ::: if you're calling it from another package (and see
> the lengthly recent discussion on that issue).  The key distinction is
> whether the function is exported or not: You must document any
> function that you export. You don't have to document any function you
> don't export.
>
> Hadley
>
> On Thu, Aug 29, 2013 at 2:15 PM, Jonathan Greenberg  wrote:
>> I had a similar question awhile ago.  Basically, my understanding is
>> if it is a function, it needs to be documented UNLESS you are calling
>> it via :::
>>
>> --j
>>
>> On Thu, Aug 29, 2013 at 1:11 PM, Sana Wajid  wrote:
>>> Thank you all, I appreciate your responses. Just a quick follow up
>>> question: couple of my functions are "background" or "behind the scenes"
>>> functions. Do these have to be documented in the manual as well?
>>>
>>>
>>> On Wed, Aug 28, 2013 at 5:19 PM, Geoff Jentry 
>>> wrote:
>>>
>>>> On Wed, 28 Aug 2013, Ben Bolker wrote:
>>>>
>>>>>  It may be suboptimal/there may be better ways, but what I would do in
>>>>> your situation would be to save the real twitteR results to a .Rdata file
>>>>> (e.g. put it in inst/vignetteData) and then 'fake' the twitter call: add a
>>>>> non-eval'd but echo'd chunk that appears to run the command, and an eval'd
>>>>> but non-echo'd chunk that loads the results of having run the command.
>>>>>
>>>>
>>>> Interesting, I'll look into doing that.
>>>>
>>>> Thanks
>>>> -J
>>>>
>>>>
>>>> __**
>>>> R-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
>>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
>> --
>> Jonathan A. Greenberg, PhD
>> Assistant Professor
>> Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
>> Department of Geography and Geographic Information Science
>> University of Illinois at Urbana-Champaign
>> 607 South Mathews Avenue, MC 150
>> Urbana, IL 61801
>> Phone: 217-300-1924
>> http://www.geog.illinois.edu/~jgrn/
>> AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> Chief Scientist, RStudio
> http://had.co.nz/



-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
607 South Mathews Avenue, MC 150
Urbana, IL 61801
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Including R code from another package...

[Jonathan Greenberg]

R-developers:

I had a quick question for the group -- let's say a package I am
developing depends on a single, small function from a large
CRAN-listed package.  I can, of course, set a dependency within my own
package, but are there means by which I can include the R script + man
file DIRECTLY in my package (of course attributing the code to the
original programmer).  Does it require me asking the package manager
directly?  If not, what is the proper way to cite that a given script
was coded by someone else?  Cheers!

--j

-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Suggestions for an "official" place to store permissions/options for a package?

[Jonathan Greenberg]

R-developers:

Duncan Murdoch suggested I move a post I started on r-help over here,
since it is more at the developer level.  Here is my
question/challenge -- to my knowledge, there is not currently an
official way to store a *package*'s options to a standardized location
on a user's computer.  Given that OS-level programs have standard
preference locations, I was hoping to first assess:

- Does R, in fact, have a place for a *package* to store preferences
(a file-based "setOptions") that would be persistent across sessions.

One suggestion that was given was to perhaps write these options to
the .RProfile, but this strikes me as potentially dangerous -- a
poorly written function to write to a user's .RProfile could corrupt
it.

If the answer to the initial question is "no" (there is not an
official location/approach for a package to store its own files), I'd
like to suggest we open this for a wider discussion amongst the
developers, to perhaps come up with a general (not package-by-package)
solution for a package to store options (and perhaps other files) in a
standard location.

The particular application that has brought me to asking about this is
that I'm writing a package that has external calls to command-line
programs that may not be properly registered with a user's environment
(think: Windows, in particular, although I've found issues with a Mac
as well), so the first step of these R - wrapper functions is to
search a user's local machine for the binaries.  If it finds it, it
stores the path to this binary as an option.  Since this is a
brute-force search, this can take some time and, ideally, this
information would be preserved across sessions, without the function
having to re-search their drive every time they start R fresh.

--j


-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Question about selective importing of package functions...

[Jonathan Greenberg]

I'm working on an update for my CRAN package "spatial.tools" and I noticed
a new warning when running R CMD CHECK --as-cran:

* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Jonathan Asher Greenberg '
Depends: includes the non-default packages:
  'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach'
  'doParallel' 'rgeos'
Adding so many packages to the search path is excessive
and importing selectively is preferable.

Is this a warning that would need to be fixed pre-CRAN (not really sure
how, since I need functions from all of those packages)?  Is there a way to
import only a single function from a package, if that function is a
dependency?

--j

-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Question about selective importing of package functions...

[Jonathan Greenberg]

Duncan:

Thanks -- learning something new today -- quick follow-up, will using the
import statements in the NAMESPACE, when a user goes to install.packages(),
auto-install the "dependent" packages the same way Depends forces?

--j


On Sun, Oct 20, 2013 at 3:49 PM, Duncan Murdoch wrote:

> On 13-10-20 4:43 PM, Jonathan Greenberg wrote:
>
>> I'm working on an update for my CRAN package "spatial.tools" and I noticed
>> a new warning when running R CMD CHECK --as-cran:
>>
>> * checking CRAN incoming feasibility ... NOTE
>> Maintainer: 'Jonathan Asher Greenberg '
>> Depends: includes the non-default packages:
>>'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach'
>>'doParallel' 'rgeos'
>> Adding so many packages to the search path is excessive
>> and importing selectively is preferable.
>>
>> Is this a warning that would need to be fixed pre-CRAN (not really sure
>> how, since I need functions from all of those packages)?  Is there a way
>> to
>> import only a single function from a package, if that function is a
>> dependency?
>>
>
> You really want to use imports.  Those are defined in the NAMESPACE file;
> you can import everything from a package if you want, but the best style is
> in fact to just import exactly what you need.  This is more robust than
> using Depends, and it doesn't add so much to the user's search path, so
> it's less likely to break something else (e.g. by putting a package on the
> path that masks some function the user already had there.)
>
> Duncan Murdoch
>
>


-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Question about selective importing of package functions...

[Jonathan Greenberg]

One more follow-up -- will I now need to include a library() statement in
each function?

--j


On Sun, Oct 20, 2013 at 3:58 PM, Gabor Grothendieck  wrote:

> On Sun, Oct 20, 2013 at 4:49 PM, Duncan Murdoch
>  wrote:
> > On 13-10-20 4:43 PM, Jonathan Greenberg wrote:
> >>
> >> I'm working on an update for my CRAN package "spatial.tools" and I
> noticed
> >> a new warning when running R CMD CHECK --as-cran:
> >>
> >> * checking CRAN incoming feasibility ... NOTE
> >> Maintainer: 'Jonathan Asher Greenberg '
> >> Depends: includes the non-default packages:
> >>'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach'
> >>'doParallel' 'rgeos'
> >> Adding so many packages to the search path is excessive
> >> and importing selectively is preferable.
> >>
> >> Is this a warning that would need to be fixed pre-CRAN (not really sure
> >> how, since I need functions from all of those packages)?  Is there a way
> >> to
> >> import only a single function from a package, if that function is a
> >> dependency?
> >
> >
> > You really want to use imports.  Those are defined in the NAMESPACE file;
> > you can import everything from a package if you want, but the best style
> is
> > in fact to just import exactly what you need.  This is more robust than
> > using Depends, and it doesn't add so much to the user's search path, so
> it's
> > less likely to break something else (e.g. by putting a package on the
> path
> > that masks some function the user already had there.)
>
> That may answer the specific case of the poster but how does one
> handle the case
> where one wants the user to be able to access the functions in the
> dependent package.
>
> For example, sqldf depends on gsubfn which provides fn which is used
> with sqldf to
> perform substitutions in the SQL string.
>
> library(sqldf)
> tt <- 3
> fn$sqldf("select * from BOD where Time > $tt")
>
> I don't want to ask the user to tediously issue a library(gsubfn) too since
> fn is frequently needed and for literally years this has not been
> necessary.
> Also I don't want to duplicate fn's code in sqldf since that makes the
> whole
> thing less modular -- it would imply having to change fn in two places
> if anything
> in fn changed.
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
>



-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Question about selective importing of package functions...

[Jonathan Greenberg]

To be clear, if I used Depends: somepackage before, and switched over to
using Imports: somepackage, I'll need to mod my code that used to have a
call to, say, somefunction to now have somepackage::somefunction, correct?

--j


On Sun, Oct 20, 2013 at 5:34 PM, Dirk Eddelbuettel  wrote:

>
> On 20 October 2013 at 16:20, Jonathan Greenberg wrote:
> | One more follow-up -- will I now need to include a library() statement in
> | each function?
>
> No.
>
> NAMESPACE entry, coupled with Imports: in DESCRIPTION.
>
> Dirk
>
> --
> Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
>



-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Where to drop a python script?

[Jonathan Greenberg]

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

-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Where to drop a python script?

[Jonathan Greenberg]

This was actually the little script I was going to include (prompting me to
ask the question): a test for the python version number.
Save this (between the ***s) as e.g. python_version.py:

***

import sys
print(sys.version_info)

***

I've done almost no python coding, so I was going to call this with a
system("/pathto/python /pathto/python_version.py",intern=TRUE) call and
post-process the one-line text output.

--j


On Thu, Oct 31, 2013 at 12:45 PM, Paul Gilbert wrote:

>
>
> 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<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@r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
>>>>>
>>>>
>>>>
>>>>
>>
>>
> __**
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
>



-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel