Movatterモバイル変換


[0]ホーム

URL:


Frequently asked questions

Konrad Rudolph

2025-11-25

General

Can I calllibrary/require/source inside amodule?

No, this usually won’t work:library (andrequire) attaches namesglobally, rather thaninside the calling module. Inside a module,box::use mustbe used instead.

Likewise, by defaultsource evaluates the source code inthe global rather than in a local environment. This behaviour can bechanged by setting itslocal argument to a suitablevalue.

Calling these functions inside a module will raise a warning whichcan be silenced by settingoptions(box.warn.legacy = FALSE). After changing thisoption, ‘box’ needs to be (unloaded and) reloaded for the change to takeeffect.

Can I use “meta packages” like ‘tidyverse’ with ‘box’?

No. You can useindividual packages from the tidyverse viabox::use. But directly loading a “meta package” such as‘tidyverse’ is intentionally not supported.

“Meta packages” such as ‘tidyverse’ are antithetical to the purposeof ‘box’: the whole point of ‘box’ is to make package importsexplicit, and to limit the number of names that are attached inthe current scope. Using “meta packages” would undermine this and istherefore discouraged.

How to organise globally installed modules?

Module names need to befully qualified, meaning that usingthem requires providing a name consisting of a prefix (at least onehigh-level namespace) and the module’s proper name. The choice of prefixis, to some extent, arbitrary. However, there are some commonconventions that are worth following.

For example, it is common practice to use a company or user name(look at code sharing websites such as GitHub for inspiration). Aproject consisting of several nested modules might also serve the samepurpose. For example, if ‘dplyr’ were implemented as a module, itscommon fully qualified name would probably betidyverse/dplyr.

As a concrete example, consider the following modules, stored in themodule search path:

‹box.path›├── klmr│   ├── fun│   ├── ggplots│   └── sys├── mschubert│   └── ebits└── …

Using thesys module (more precisely,klmr/sys) requires the following R code:

box::use(klmr/sys)

Common error messages

“object ‘X’ not found” inside a module

Inside modules, only the ‘base’ package is attached.Allother packages need to be attached, including all core R packages thatare otherwise attached by default. This includes ‘stats’, ‘graphics’,‘grDevices’, ‘utils’, ‘datasets’ and ‘methods’.

To use names from any of these packages, the packages need to beloaded viabox::use, same as third-party packages.Alternatively, the standard moduler/core can be used (and,optionally, attached):

box::use(r/core[...])

This is equivalent to using and attaching the default R packages‘methods’, ‘stats’, ‘graphics’, ‘grDevices’ and ‘utils’, and istherefore similar to the state of a regular R session.

This module ships with ‘box’ and is always findable.

“there is no package called ‘X’” when runningbox::use(X), even though the module ‘X’ exists

box::use(name) never attempts to load a module, italways attempts to load apackage called ‘name’, and fails ifno such package exists. Modules need to be eitherlocal andstart with. or.., or they need to be fullyqualified. This means that the full module name contains at least oneseparator (/).

In practice, this means that modules inside the global module searchpath (set via the environment variableR_BOX_PATH or viagetOption('box.path')), modules need to be located innested folders.

Seehow toorganise globally installed modules? for details.


[8]ページ先頭

©2009-2025 Movatter.jp