Imports - functions with the same name but from different package - r

I'm working on update of my package. However I'm struggling with dependencies/imports. I use two conflicted packages - ggplot2 and psych and their functions alpha and of course alpha object of ggplot2 differs from alpha function of psych package.
When building package I get an warning:
Warning: replacing previous import 'ggplot2::alpha' by 'psych::alpha' when loading 'ShinyItemAnalysis'
Hence I wont be able to publish my package on CRAN (untill I solved this warning). Is there any easy way how to avoid this import conflict?

Note that when using roxygen2 package to build NAMESPACE from fellow .R scripts, it is very helpful to delete the NAMESPACE file and run roxygen2 again. Solves many problems.

Related

Conflicted package in R package building

I am creating my first package, here I am making some var estimations, the functions are running, however, I use packages that have the same function names.
Before writing the package I made an R script with the function and tests if it works, but at the top of my script I used the following code:
invisible(lapply(c("tibble","readxl","dplyr","stringr", "tidyr", "vars", "conflicted","forecast", "lubridate"), library, character.only = T))
conflict_prefer("select","dplyr")
conflict_prefer("lag", "dplyr")
conflict_prefer("filter", "dplyr")
The conflicted package chose the functions select, lag, and filter comes from the dplyr package rather from the stats package.
So I have not figured out how to use the conflict_prefer function inside the package.
Should they be the first lines of my function?
There is a roxygen way to prefer same-name functions?
I ask this because I get this warning:
> devtools::load_all()
i Loading FAVAR.MEF
Warning messages:
1: replacing previous import ‘dplyr::filter’ by ‘stats::filter’ when loading ‘FAVAR.MEF’
2: replacing previous import ‘dplyr::lag’ by ‘stats::lag’ when loading ‘FAVAR.MEF’
3: replacing previous import ‘stats::filter’ by ‘dplyr::filter’ when loading ‘FAVAR.MEF’
4: In setup_ns_exports(path, export_all, export_imports) :
Objects listed as exports, but not present in namespace: favar_est
Thanks in advance!!
If you are writing your own package and using external dependencies, you should not load them through repeated calls to library.
The proper way to do it is to state your dependencies in the DECRIPTION file of your package, which will mean that your dependencies are put on the search path in the correct order when your package is loaded. In your case, this removes the need for conflict_prefer, as dplyr will be higher up on the search path than stats. It also makes your package portable, because anyone who installs your package will have any missing dependencies installed automatically according to the packages listed in your DESCRIPTION file. Furthermore, doing it this way allows you to specify a minimum version of the dependency, so that anyone who already has an older version of the dependency installed will not come up against an obscure error when they try to use your package.
The DESCRIPTION file resides in the root directory of your package. It is a simple text file.
You need only add:
Depends:
tibble,
readxl,
dplyr,
stringr,
tidyr,
vars,
conflicted,
forecast,
lubridate
within this file, and your dependencies will be loaded with your package.

NAMESPACE issue: multiple packages import and export an identical function

I am writing a small package to do some routine data analysis and I wish to include some easy mapping functions. My package imports tidyr, dplyr, and leaflet (from RStudio on Github). When I build or load my package I get the warning:
replacing previous import by ‘leaflet::%>%’ when loading ‘MyPackage’
Looking at the NAMESPACE files of leaflet, dplyr and tidyr, I find that all three have
importFrom(magrittr,"%>%")
and
export("%>%")
So basically all 3 are importing and exporting the same function from the magrittr package. Is there some way I can resolve this within may package so that the warning is no longer generated (not just suppressed)? Is it something I should just ignore?

cover function (?) : how to deal with dependencies packages while developing new package in r

My the R package depends upon other package (for example "fields")
What is best practice to ensure that the package is loaded, when my package is loaded.
Should I write cover r program to do this ? Can or should such dependencies distributed with my distribution ?
I will appreciate a detail answer with scrips
Edit:
As per following suggestion I added the following in Discription file.
Depends: R (>= 1.8.0), fields
Still the fields package is not loaded automatically when I load my package.
This is something you specify in your DESCRIPTION file that you ship with your package. You can use either the 'Depends' field, or better is to use 'Imports' field in combination with a NAMESPACE file. Have a look at the DESCRIPTION and NAMESPACE files from some other packages, or read over the Writing R Extensions manual.

How to properly use functions from other packages in a R package

I am a bit confused about this. I have an R package that has a small function (not a mayor part of the package) in which the principal function of the psych package is called. How do I correctly specify this in DESCRIPTION and NAMESPACE?
Setting Depends: psych in DESCRIPTION makes sure the psych package is loaded every time my package is loaded. This works, but it seems redundant for such a small part of my package.
Setting Suggests: psych and entering a require("psych") in the function is what I do now, however this does not work if psych is not installed, and seems to be the wrong way of doing this (writing R extensions says that suggest is meant mainly for examples).
I think I need to import the function. I tried setting Imports: psych in DESCRIPTION and importFrom(psych,"principal") in NAMESPACE. This works, but on a computer that does not has psych installed it gives an error when loading my package.
The basic question you need to answer is: "do you want the function to be available to all users of the package without further effort?". If yes, then use imports + the appropriate namespace declarations, if no, then use suggests and print an informative error message if require("psych") returns FALSE.
I don't understand your import related complaint that: "but on a computer that does not has psych installed it gives an error when loading my package". This is also true if your package is in depends!

Loading depending packages using .onLoad

My package requires ggplot2 package, but I am having trouble to fix the following NOTES that I get when I run R CMD check.
no visible global function definition for qplot
'library' or 'require' call not declared from: ggplot2
I also have a .onLoad function,
.onLoad <- function(libname, pkgname){
.libPaths("~/RLibrary")
require(ggplot2)
}
Any suggestions on how to solve the errors? Where should I place the onLoad function?
Thank you
San
I don't think you should do it like that. It is best to either make your package depend on ggplot2 or import the namespace of ggplot2. Do the in the DESCRIPTION file by adding Depends: ggplot2 and the second by adding Imports: ggplot2 in DESCRIPTION and import(ggplot2) in NAMESPACE (or be more exact with importfrom(ggplot2,"somefunction").
Alternatively you could set Suggests: ggplot2 in DESCRIPTION and put a require("ggplot2") in any functions that uses it, but I don't like this alot.
See also:
http://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file
EDIT: To be a bit more clear. With Depends the package is loaded every time your package is loaded and its functions are all available for the user.
With Imports you can use the functions of the package, but the package is not loaded when your package is not loaded (functions are not available to the user).
With Suggests the package is not loaded when you load your package and you can't use its functions. You need to declare a require somewhere to use them. Basically this can be used to make clear that you use this package somewhere (in an example or so).
It all depends on how you want your users to be able to use the depended package and how important it is for your package. For example, if your package is a frontend to ggplot2 Depends is best, if it does some analysis and has an plot function Imports is best.

Resources