Managing imports and exports

The package NAMESPACE is one of the most confusing parts of building a package. roxygen2 aims to make it as easy as possible to build a package that is a well-behaved member of the R ecosystem. This is a little frustrating at first, but soon becomes second-nature.


For a function to be usable outside your package, you must export it. By default roxygen2 doesn’t export anything from your package. If you want an object to be publicly available, you must explicitly tag it with @export.

Use the following guidelines to decide what to export:

S3 methods for generics in suggested packages

@exportS3Method tag allows you to generate S3method() namespace directives. Its primary use is for “delayed” method registration, which allows you to define methods for generics found in suggested packages (R >= 3.6). For example,

#' @exportS3Method pkg::generic <- function(x, ...) {

will generate

S3method(pkg::generic, foo)

Which will cause the method to be registered only when pkg is loaded.

Manual exports

If @export does not automatically generate the correct directive when, you can use one of the tags below to exercise greater control:

For even more specialised cases you can use @rawNamespace code which inserts code literally into the NAMESPACE. If you need to automate this, @evalNamespace fun() will evaluate fun() in the package environment and insert the results into NAMESPACE. Because evalNamespace() is run in the package environment, it can only generate exports, not imports.


The NAMESPACE also controls which functions from other packages are made available to your package.


If you are using just a few functions from another package, we recommending adding the package to the Imports: field of the DESCRIPTION file and calling the functions explicitly using ::, e.g., pkg::fun().

my_function <- function(x, y) {
  pkg::fun(x) * y

If the repetition of the package name becomes annoying you can @importFrom and drop the :::

#' @importFrom pkg fun 
my_function <- function(x, y) {
  fun(x) * y

Imports affect every function in a package, so it’s common to collect them in a central place, like {packagename}-package.R. This is automated by usethis::use_import_from().

#' @importFrom pkg fun1 fun2
#' @importFrom pkg2 fun3
#' @importFrom pkg3 fun4

Note the use of NULL here: you must provide something for roxygen2 to document, so we use NULL as place holder.

It is possible, but not generally recommended to import all functions from a package with @import package. This is risky if you import functions from more than one package, because while it might be ok today, in the future the packages might end up with a function having the same name, and your users will get a warning every time your package is loaded.


S3 generics are just functions, so the same rules for functions apply. S3 methods always accompany the generic, so as long as you can access the generic (either implicitly or explicitly), the methods will also be available. In other words, you don’t need to do anything special for S3 methods. As long as you’ve imported the generic, all the methods will also be available.


Compiled code

To import compiled code from another package, use @useDynLib