Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Project profiles

Source:vignettes/profiles.Rmd
profiles.Rmd

Introduction

Starting withrenv 0.13.0, it is possible to activateand switch between different profiles associated with a project. Aprofile can be thought of as a different mode in which a project isused. For example:

  • A “development” profile might be used when developing and testing aproject,
  • A “production” profile might be used for productiondeployments,
  • A “shiny” profile might be used when running the Shinyapplication.

At its heart, activating or using a particular profile implies usinga different set of paths for the project library and lockfile. Withthis, it is possible to associate different packages, and differentdependencies, with different workflows in a single project usingrenv.

Usage

By default, renv projects use the “default” profile, which impliesthat library and lockfile paths are set in the typical way. To activatea particular profile, use:

renv::activate(profile="dev")

This creates a profile called"dev", and sets it as thedefault for the project, so that newly-launched R sessions will operateusing the"dev" profile. After setting this andre-launching R, you should see that the project library and lockfilepaths are resolved within therenv/profiles/dev folder fromthe project root.

Alternatively, if you want to activate a particular profile for an Rsession without setting it as the default for new R sessions, you canuse:

Sys.setenv(RENV_PROFILE="dev")

and renv will automatically use that profile as appropriate whencomputing library and lockfile paths. Similarly, from the command line,you might enforce the use of a particular profile in an renv projectwith:

exportRENV_PROFILE=dev

With that set, renv would default to using the"dev"profile for any newly-launched R sessions within renv projects.

To activate the “default” profile used by a project, use:

renv::activate(profile="default")

Managing profile-specific dependencies

Profile-specific package dependencies can be declared within theproject’s top-levelDESCRIPTION file. For example, todeclare that the shiny profile depends on theshiny andtidyverse packages:

Config/renv/profiles/shiny/dependencies: shiny, tidyverse

If you’d like to also declare that these packages should be installedfrom a custom remote (analogous to theRemotes field forthe default profile), you can define those remotes with a separatefield:

Config/renv/profiles/shiny/remotes: rstudio/shiny, tidyverse/tidyverse

These remotes will then be respected in calls torenv::install().

The packages and remotes must be specified separately, as renv cannotdetermine the package name associated with a particular remote withoutexplicitly resolving that remote. Remote resolution normally requires aweb request, which renv tries to avoid in “regular” dependencydiscovery.

If you’d prefer that only the packages enumerated in this field areused, you can opt-in to using"explicit" snapshots, andleave theImports,Depends andSuggests fields blank:

renv::settings$snapshot.type("explicit")

When set, only the dependencies listed in the projectDESCRIPTION file will be used when the lockfile isgenerated. See?renv::snapshot for more details.


[8]ページ先頭

©2009-2025 Movatter.jp