Chapter 10. Dependencies: Mindset and Background

You take a dependency when your package uses functionality from another package (or other external tool). In “Imports, Suggests, and Friends”, we explained how to declare a dependency on another package by listing it in DESCRIPTION, usually in Imports or Suggests. But that still leaves many issues for you to think about:

  • When should you take a dependency? What are the risks and rewards? In “When Should You Take a Dependency?” we provide a framework for deciding whether a dependency is worth it. This chapter also includes specific sections for deciding between Imports and Suggests (see “Whether to Import or Suggest”) and between Imports and Depends (see “Whether to Import or Depend”).

  • How should you use different kinds of dependencies in different contexts? That is, imported versus suggested packages, used inside your functions versus tests versus documentation. We have to defer this to the next chapter (Chapter 11), because the justification for those recommendations relies on some additional technical background that we develop here.

A key concept for understanding how packages are meant to work together is that of a namespace (see “Namespace”). Although it can be a bit confusing, R’s namespace system is vital for the package ecosystem. It is what ensures that other packages won’t interfere with your code, that your code won’t interfere with other packages, and that your package works regardless of the environment in which ...

Get R Packages, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.