1

If I am making a package, let's call it "P," that imports methods from packages "Q" and "R," is there an effective way to manage the methods accessible to users when the package is built?

That is, say package "Q" is actually the 'shiny' package. The package, in and of itself, is an interface, and so it obviously uses a LOT of shiny methods. Likewise, "R" is ggplot2 and the package makes use of a number of methods from it.

When I build the package, a user could import the package and select 'ggplot' under the namespace of "P." I don't want this to happen, as the user now has access to ~40-50 methods of which I don't want access given. I would rather the user only be able to import the package and use the methods developed in the new package, NOT the methods from ggplot2 or shiny.

How can I import the methods of shiny and ggplot2 in development of my package... but NOT have these methods public to users? I have seen, in researching this problem, require([package]) as a possible line in Roxygen code snippets, but am unsure of how to include such, as @require doesn't exist.

Edit: Including the DESCRIPTION imports and NAMESPACE file for relevant background information.

Imports: 
    config (>= 0.3.1),
    deSolve (>= 1.31),
    ggplot2 (>= 3.3.5),
    ggpubr (>= 0.4.0),
    golem (>= 0.3.2),
    shiny (>= 1.6.0),
    utils (>= 4.0.5)

import(shiny)
importFrom(deSolve,ode)
importFrom(ggplot2,aes)
importFrom(ggplot2,geom_point)
importFrom(ggplot2,ggplot)
importFrom(ggplot2,ggsave)
importFrom(ggplot2,labs)
importFrom(ggpubr,theme_pubr)
importFrom(golem,with_golem_options)
importFrom(shiny,NS)
importFrom(shiny,shinyApp)
importFrom(shiny,tagList)
importFrom(utils,write.csv)
importFrom(utils,zip)
Carter Hall
  • 11
  • 2
  • Make sure you don't re-export the functions in your own package. That should be the default though. It's unclear exactly how you've included these dependencies your package currently. It's easier to help you if you provide a [reproducible example](https://stackoverflow.com/questions/5963269/how-to-make-a-great-r-reproducible-example) with sample code that can be used to test and verify possible solutions. What exactly does your NAMESPACE file look like? Are you using "depends" or "imports" in your DESCRIPTION file? – MrFlick Jun 27 '22 at 16:19
  • I can mock-up a reproducible example, sure; I'd have to make a new package altogether, though, as the package itself is part of a company project. The NAMESPACE currently is a host of import([package]) and export([method]) commands. The description has all of these packages, with specified version, in the Imports section. Though, to be clear, the 'export' calls are methods I develop. – Carter Hall Jun 27 '22 at 16:22
  • 1
    Are you actually installing the package to test things? Or are you using something like `devtools`?` If the latter, try `devtools::load_all(export_all=FALSE)`. I think `devtools` is just trying to be too helpful here. – MrFlick Jun 27 '22 at 16:33
  • The package is built using golem, so I am using devtools::document(), then devtools::check(). When I run rhub::check_for_cran() and devtools::build(), the package builds. The way I'm checking what methods are accessible is, quite simply, under an empty environment: library(package) and package:: + 'Tab' in the console. What does the method you supplied do? More importantly, what does it do in the context of package-building? I'll look into it myself aswell :) – Carter Hall Jun 27 '22 at 16:40
  • Just ran it... it loads the package, but I can still call EVERY. METHOD. USED. Right down to the header methods h1() and the like. :/ – Carter Hall Jun 27 '22 at 16:45
  • 1
    The use of `devtools` might be the key to what you are seeing. If you `devtools::load_all` or `::document` your package, then it might be useful to use `devtools::load_all(..., export_all=FALSE)`. When the package is built and loaded "normally" (i.e., not via `devtools`), then this need goes away. – r2evans Jun 27 '22 at 16:47
  • 1
    Got it! I believe that's actually working on my end -- I've put it in my deployment file, just in case; calling library(package) now gives me ONLY the methods I want to see! Thank you *both* for the help! – Carter Hall Jun 27 '22 at 16:50
  • 1
    If you "deploy" the package as a tarball or zip file, then those installing it will not have the problems you're seeing. The problem of (re)exporting everything is purely a symptom of using `devtools` while developing the package. (However, if the default use in the deployment file is to us `devtools`, then you will need it.) FYI, you never need `library(package)` if you use `devtools::load_all(package)` with or without `export_all=FALSE` since `load_all`'s intent is to load it as a package in its own namespace. – r2evans Jun 27 '22 at 17:07
  • Got it! I finally got it to work a week ago, but wanted to say thanks! – Carter Hall Jul 08 '22 at 19:23

0 Answers0