I am trying to use the downscaleR package to downscale future precipitation data, and I notice that the downscaleR package provides different methods to achieve this.
https://github.com/SantanderMetGroup/downscaleR
When I try to follow the delta method example, I notice the error "could not find function "quickDiagnostics".
https://github.com/SantanderMetGroup/downscaleR/wiki/calibration-and-cross-validation
In addition, I have followed the example "Perfect Prognosis Approach: Application to Seasonal Forecasts" available at http://meteo.unican.es/work/downscaler/wiki/html/PPapplycationSeasonalForecast.html. However, the “loadMultiField" and "plotMeanField" functions are not available.
I have loaded the packages downscaleR, transformeR, visualizeR, loadeR, climate4R.UDG, and climate4R.datasets. I wonder if the above functions have been excluded from the package, or do I need to install another package? Thanks for any help.
Looking at the GitHub commit history:
remove function quickDiagnostics and dependencies, committed on May 25, 2020
https://github.com/SantanderMetGroup/downscaleR/commit/f85ad1533d3f8579d6072e35b880b82de6c0408e
Related
Long story short:
My aim is to submit a R package developed with roxygen2 to CRAN, and I need to find some guidelines on writing and documenting hidden functions.
More details:
I am writing my first R package using roxygen2 in Rstudio. I have documented all the functions I wrote so far, so that my collaborators can easily understand their purpose before going into the details of the script. All the functions that are of no use to the user, but necessary to the package, are not exported in the namespace and eliminated from the package manual/index (#keywords internal). At the same time, my collaborators can still read their documentation using the help of Rstudio.
Eventually, I would like to remove the documentation of these "hidden functions" from the help because there is no reason to keep it. I was considering to follow a suggestion I found in other posts, that is changing #' with ## in the documentation created with roxygen2. However, I am not sure this is the correct procedure to implement, and if removing the documentation of a function in the help and the manual is compatible with CRAN requirements.
Can anyone point me to some guidelines related to this issue, or has any experience to share?
I'm developing an R package which needs to use parallelisation as made available by the snowfall package. snowfall doesn't seem to import the same was as other packages like ggplot2, data.table, etc. I've included snowfall, rlecuyer, and snow in the description file, name space file, and as an import argument in the function itself. When I try to access this function, I get the following error:
Error in sfInit() : could not find function "setDefaultClusterOptions"
The sfInit function seems to have a nostart / nostop argument which it says is related to nested usage of sfInit but that doesn't seem to do the trick for me either.
The actual code itself uses an sfInit (which is where I get the error), some sfExports and sfLibrarys, and an sfLapply.
Possible solution:
It seems to work if I move snow from the import section to the depends section in the Desciption file. I don't know why though.
When you include a package in 'Depends' when one attaches your package they also attach the package on which your package Depends to their namespace.
This and other differences between Depends and Imports is explained well in other questions on this site.
If you look at {snowfall}'s DESCRIPTION you'll see that it Depends on {snow}. It is plausible that the authors of snowfall know something we don't and that {snow} has to be attached to the global search path in order to work. In fact that is the top caveat in the top answer to the question I linked above...
... if your package relies on a package A which itself "Depends" on
another package B, your package will likely need to attach A with a
"Depends directive.
This is because the functions in package A were written with the
expectation that package B and its functions would be attached to the
search() path.
So, in your case, it just so happens that all {snowfall} wants is {snow} and you happened to provide it. However, it appears the more correct behavior may be for you to Depend on {snowfall} directly.
setDefaultClusterOptions is a function from the snow package. You need to import that too.
I'm working on an R package here and got this doubt: I need an auxiliar function from another package, but I don't want to include the entire package as a dependency because I only need this one function. What is the correct procedure here? Is it OK if both codes are GPL-2 and I just copy/paste the function to my package? Should I contact the author? Or is it best to include the whole package as a dependency?
If it's just a small function, I don't see a problem with copying the code into your own package (since everything is GPLed). You should acknowledge the source in your package though.
This has the benefit of insulating your code from any changes in the other package; it's not unusual for updates to packages to break other packages downstream. It has the downside that if those updates were useful (bug fixes or added functionality) then you don't benefit from them either.
I am working on a family of R packages, all of which share substantial common code which is housed in an internal package, lets call it myPackageUtilities. So I have several packages
myPackage1, myPackage2, etc...
All of these packages depend on every method in myPackageUtilities. For a real-world example, please see statnet on CRAN. Each dependent package, of course, has
Depends: myPackageUtilities
in its DESCRIPTION file.
My question is: In the R code for myPackage1, which of the following two techniques for accessing methods from myPackageUtilities is preferable:
Use ::: to access the methods in myPackageUtilities, or
Export everything from myPackageUtilities (e.g. by including exportPattern("^[^\\.]") in the NAMESPACE)?
Option 2 clutters the end-user's search path, but the R gurus recommend against using :::.
Follow-up question: If (2) is the better choice, is there a way to export everything using roxygen2?
Suppose we have a package called randomUtils and this package has a function called sd that calculates the Slytherin Defiance Quotient.
Now I write a package called spellbound. If spellbound Depends on randomUtils, then randomUtils::sd will be found in the search path and can conflict with calculating standard deviation.
If spellbound Imports randomUtils, however, then R will install randomUtils but will not load it when spellbound is loaded. Thus, the new version of sd can't be found on the search path, but can still be accessed by randomUtils::sd
With an ever growing body of contributed work on CRAN, it is becoming very important that we use Imports as much as possible so that we don't introduce unexpected behaviors by having conflicting function definitions.
An example of when I have used Depends: when writing the HydeNet package, I wanted the end user to be able to use the rjags package in concert with HydeNet. So I put rjags in Depends so that library (HydeNet) would loaf both packages. (In other words, put rjags on the search path.
Moral of the story, if you don't intend for the user to directly access the functions, it should go in Imports.
Title should be pretty clear I hope. I'm writing a package called forecasting, with imports for dplyr among other packages. With the imports written in to the DESCRIPTION file, I am able to force these other packages to be installed along with forecasting - is there an equivalent way to do this for the loading of the package? In other words, is there a way that when I load my package with library(forecasting), it automatically also loads dplyr and the other packages?
Thanks
Yes.
Re-read "Writing R Extensions". The Depends: forces both the initial installation as well as the loading of the depended-upon packages.
But these days you want Imports: along with importFrom() in the NAMESPACE file which is more fine-grained.
But first things first: get it working with Depends.
Edit:
Opps you're correct, the documentation I referenced is not a primary source. Perhaps this is better:
From the R documentation:
The ‘Depends’ field gives a comma-separated list of package names which this package depends on. Those packages will be attached before the current package when library or require is called.
and
The ‘Imports’ field lists packages whose namespaces are imported from (as specified in the NAMESPACE file) but which do not need to be attached. Namespaces accessed by the ‘::’ and ‘:::’ operators must be listed here, or in ‘Suggests’ or ‘Enhances’
Original:
From the R packages documentation:
Adding a package dependency here [the DESCRIPTION file] ensures that it’ll be installed. However, it does not mean that it will be attached along with your package (i.e., library(x)). The best practice is to explicitly refer to external functions using the syntax package::function(). This makes it very easy to identify which functions live outside of your package. This is especially useful when you read your code in the future.