#MAYA PYTHON LS IGNORE NAMESPACE CODE#
The following code is an excerpt of the NAMESPACE file from the testthat package. In the section after that, you’ll learn the details of exporting and importing functions and other objects. You’ll learn what this file looks like in the next section. The two sides of the package namespace, imports and exports, are both described by the NAMESPACE. Now that you understand the importance of the namespace, let’s dive into the nitty gritty details. Similarly, ggplot2 should really Depend on scales, rather than Importing it. It’s not useful without vegan, so it has vegan in Depends instead of Imports. For example, the analogue package builds on top of vegan. The only exception is if your package is designed to be used in conjunction with another package. That’s because a good package is self-contained, and minimises changes to the global environment (including the search path). Unless there is a good reason otherwise, you should always list packages in Imports not Depends. The rest of the advice in this chapter applies whether or not the package is in Depends or Imports. The main difference is that where Imports just loads the package, Depends attaches it. Listing a package in either Depends or Imports ensures that it’s installed when needed. What’s the difference between Depends and Imports in the DESCRIPTION? When should you use one or the other? Now’s a good time to come back to an important issue which we glossed over earlier. You should never use require() or library() in a package: instead, use the Depends or Imports fields in the DESCRIPTION. You never need to use require() ( requireNamespace() is almost always better), or loadNamespace() (which is only needed for internal R code). Specific action (e.g. throw an error) depending on whether or not Use requireNamespace("x", quietly = TRUE) inside a package if you want a
Package is not installed, and will terminate the script. Of the four, you should only ever use two: If we use library(), testthat is attached to the search path. To see the differences more clearly, consider two ways of running expect_that() from the testthat package. If a package isn’t installed, loading (and hence attaching) will fail with an error. You can see the currently attached packages with Package without first loading it, so both library() or require() load It’s rare to load a package explicitly, but youĬan do so with requireNamespace() or loadNamespace().Īttaching puts the package in the search path. Path, you won’t be able to access its components without using .Ĭonfusingly, :: will also load a package automatically if it
Package is available in memory, but because it’s not in the search Loading will load code, data and any DLLs register S3 and Normally when you talk about loading a package you think of library(), but that actually attaches the package. There’s an important difference between loading and attaching a package. Search ( ) #> ".GlobalEnv" "package:stats" "package:graphics" #> "package:grDevices" "package:utils" "package:datasets" #> "package:methods" "Autoloads" "package:base" To illustrate, consider what happens when someone changes the definition of a function that you rely on: for example, the simple nrow() function in base R: The imports defines how a function in one package finds a function in another. Namespaces make your packages self-contained in two ways: the imports and the exports. Then the order in which the packages are loaded won’t matter. Instead, you can explicitly refer to specific functions: Hmisc::summarize() and plyr::summarize(). But if you load the packages in the opposite order, summarize() will refer to the plyr version. If you load plyr, then Hmisc, summarize() will refer to the Hmisc version. For example, both plyr and Hmisc provide a summarize() function. For example, have you ever used the :: operator? It disambiguates functions with the same name. Without knowing it, you’ve probably already used namespaces. They provide a context for looking up the value of an object associated with a name. As the name suggests, namespaces provide “spaces” for “names”.
0 kommentar(er)
