setup: Individual setup* functions that are contained within...
In PredictiveEcology/SpaDES.project: Project Templates Using 'SpaDES'
setupPaths R Documentation
Individual setup* functions that are contained within setupProject
Description
These functions will allow more user control, though in most circumstances,
it should be unnecessary to call them directly.
Usage
setupPaths(
name,
paths,
inProject,
standAlone = TRUE,
libPaths = NULL,
updateRprofile = getOption("SpaDES.project.updateRprofile", TRUE),
Restart = getOption("SpaDES.project.Restart", FALSE),
overwrite = FALSE,
envir = parent.frame(),
useGit = getOption("SpaDES.project.useGit", FALSE),
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
...
)
setupFunctions(
functions,
name,
sideEffects,
paths,
overwrite = FALSE,
envir = parent.frame(),
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
...
)
setupSideEffects(
name,
sideEffects,
paths,
times,
overwrite = FALSE,
envir = parent.frame(),
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
...
)
setupOptions(
name,
options,
paths,
times,
overwrite = FALSE,
envir = parent.frame(),
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
useGit = getOption("SpaDES.project.useGit", FALSE),
updateRprofile = getOption("SpaDES.project.updateRprofile", TRUE),
...
)
setupModules(
name,
paths,
modules,
inProject,
useGit = getOption("SpaDES.project.useGit", FALSE),
overwrite = FALSE,
envir = parent.frame(),
gitUserName,
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
updateRprofile = getOption("SpaDES.project.updateRprofile", TRUE),
...
)
setupPackages(
packages,
modulePackages = list(),
require = list(),
paths,
libPaths,
setLinuxBinaryRepo = TRUE,
standAlone,
envir = parent.frame(),
verbose = getOption("Require.verbose"),
dots,
defaultDots,
...
)
setupParams(
name,
params,
paths,
modules,
times,
options,
overwrite = FALSE,
envir = parent.frame(),
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
...
)
setupGitIgnore(
paths,
gitignore = getOption("SpaDES.project.gitignore", TRUE),
verbose
)
setupStudyArea(
studyArea,
paths,
envir,
verbose = getOption("Require.verbose", 1L)
)
Arguments
name
Optional. If supplied, the name of the project. If not supplied, an
attempt will be made to extract the name from the paths[["projectPath"]].
If this is a GitHub project, then it should indicate the full Github
repository and branch name, e.g., "PredictiveEcology/WBI_forecasts@ChubatyPubNum12"
paths
a list with named elements, specifically, modulePath, projectPath,
packagePath and all others that are in SpaDES.core::setPaths()
(i.e., inputPath, outputPath, scratchPath, cachePath, rasterTmpDir).
Each of these has a sensible default, which will be overridden but any user
supplied values.
See setup.
inProject
A logical. If TRUE, then the current directory is
inside the paths[["projectPath"]].
standAlone
A logical. Passed to Require::standAlone. This keeps all
packages installed in a project-level library, if TRUE. Default is TRUE.
libPaths
Deprecated. Use paths = list(packagePath = ...).
updateRprofile
Logical. Should the paths$packagePath be set in the .Rprofile
file for this project. Note: if paths$packagePath is within the tempdir(),
then there will be a warning, indicating this won't persist. If the user is
using Rstudio and the paths$projectPath is not the root of the current
Rstudio project, then a warning will be given, indicating the .Rprofile may not
be read upon restart.
Restart
Logical or character. If either TRUE or a character,
and if the projectPath is not the current path, and the session is in
RStudio and interactive, it will try to restart Rstudio in the projectPath with
a new Rstudio project. If character, it should represent the filename
of the script that contains the setupProject call that should be copied to
the new folder and opened. If TRUE, it will use the active file as the one
that should be copied to the new projectPath and opened in the Rstudio project.
If successful, this will create an RStudio Project file (and .Rproj.user
folder), restart with a new Rstudio session with that new project and with a root
path (i.e. working directory) set to projectPath. Default is FALSE, and no
RStudio Project is created.
overwrite
Logical vector or character vector, however, only getModule will respond
to a vector of values. If length-one TRUE, then all files that were previously downloaded
will be overwritten throughout the sequence of setupProject. If a vector of
logical or character, these will be passed to getModule: only the named
modules will be overwritten or the logical vector of the modules.
NOTE: if a vector, no other file specified anywhere in setupProject will be
overwritten except a module that/those names, because
only setupModules is currently responsive to a vector. To have fine grained control,
a user can just manually delete a file, then rerun.
envir
An environment within which to look for objects. If called alone,
the function should use its own internal environment. If called from another
function, e.g., setupProject, then the envir should be the internal
transient environment of that function.
useGit
(if not FALSE, then experimental still). There are two levels at which a project
can use GitHub, either the projectPath and/or the modules. Any given
project can have one or the other, or both of these under git control. If "both",
then this function will assume that git submodules will be used for the modules.
A logical or "sub" for submodule. If "sub", then this function
will attempt to clone the identified modules as git submodules. This will only
work if the projectPath is a git repository. If the project is already a git
repository because the user has set that up externally to this function call, then
this function will add the modules as git submodules. If it is not already,
it will use git clone for each module. After git clone or submodule add are run,
it will run git checkout for the named branch and then git pull
to get and change branch for each module, according to its specification in
modules. If FALSE, this function will download modules with getModules.
NOTE: CREATING A
GIT REPOSITORY AT THE PROJECT LEVEL AND SETTING MODULES AS GIT SUBMODULES IS
EXPERIMENTAL. IT IS FINE IF THE PROJECT HAS BEEN MANUALLY SET UP TO BE
A GIT REPOSITORY WITH SUBMODULES: THIS FUNCTION WILL ONLY EVALUTE PATHS. This can
be set with the option(SpaDES.project.useGit = xxx).
verbose
Numeric or logical indicating how verbose should the function
be. If -1 or -2, then as little verbosity as possible. If 0 or FALSE,
then minimal outputs; if 1 or TRUE, more outputs; 2 even more. NOTE: in
Require function, when verbose >= 2, also returns details as if
returnDetails = TRUE (for backwards compatibility).
dots
Any other named objects passed as a list a user might want for other elements.
defaultDots
A named list of any arbitrary R objects.
These can be supplied to give default values to objects that
are otherwise passed in with the ..., i.e., not specifically named for these
setup* functions. If named objects are supplied as top-level arguments, then
the defaultDots will be overridden. This can be particularly useful if the
arguments passed to ... do not always exist, but rely on external e.g., batch
processing to optionally fill them. See examples.
...
further named arguments that acts like objects, but a different
way to specify them. These can be anything. The general use case
is to create the objects that are would be passed to
SpaDES.core::simInit, or SpaDES.core::simInitAndSpades,
(e.g. studyAreaName or objects) or additional objects to be passed to the simulation
(in older versions of SpaDES.core, these were passed as a named list
to the objects argument). Order matters. These are sequentially evaluated,
and also any arguments that are specified before the named arguments
e.g., name, paths, will be evaluated prior to any of the named arguments,
i.e., "at the start" of the setupProject.
If placed after the first named argument, then they will be evaluated at the
end of the setupProject, so can access all the packages, objects, etc.
functions
A set of function definitions to be used within setupProject.
These will be returned as a list element. If function definitions require non-base
packages, prefix the function call with the package e.g., terra::rast. When
using setupProject, the functions argument is evaluated after paths, so
it cannot be used to define functions that help specify paths.
sideEffects
Optional. This can be an expression or one or more file names or
a code chunk surrounded by {...}.
If a non-text file name is specified (e.g., not .txt or .R currently),
these files will simply be downloaded, using their relative path as specified
in the github notation. They will be downloaded or accessed locally at that
relative path.
If these file names represent scripts (*.txt or .R), this/these will be parsed and evaluated,
but nothing is returned (i.e., any assigned objects are not returned). This is intended
to be used for operations like cloud authentication or configuration functions
that are run for their side effects only.
times
Optional. This will be returned if supplied; if supplied, the values
can be used in e.g., params, e.g., params = list(mod = list(startTime = times$start)).
See help for SpaDES.core::simInit.
options
Optional. Either a named list to be passed to options
or a character vector indicating one or more file(s) to source,
in the order provided. These will be parsed locally (not
the .GlobalEnv), so they will not create globally accessible objects. NOTE:
options is run 2x within setupProject, once before setupPaths and once
after setupPackages. This occurs because many packages use options for their
behaviour (need them set before e.g., Require::require is run; but many packages
also change options at startup. See details.
See setup.
modules
a character string of modules to pass to getModule. These
should be one of: simple name (e.g., fireSense) which will be searched for locally
in the paths[["modulePath"]]; or a GitHub repo with branch (GitHubAccount/Repo@branch e.g.,
"PredictiveEcology/Biomass_core@development"); or a character vector that identifies
one or more module folders (local or GitHub) (not the module .R script).
If the entire project is a git repository,
then it will not try to re-get these modules; instead it will rely on the user
managing their git status outside of this function.
See setup.
gitUserName
The GitHub account name. Used with git clone git@github.com:gitHuserName/name
packages
Optional. A vector of packages that must exist in the libPaths.
This will be passed to Require::Install, i.e., these will be installed, but
not attached to the search path. See also the require argument. To force skip
of package installation (without assessing modules), set packages = NULL
modulePackages
A named list, where names are the module names, and the elements
of the list are packages in a form that Require::Require accepts.
require
Optional. A character vector of packages to install and attach
(with Require::Require). These will be installed and attached at the start
of setupProject so that a user can use these during setupProject.
See setup
setLinuxBinaryRepo
Logical. Should the binary RStudio Package Manager be used
on Linux (ignored if Windows)
params
Optional. Similar to options, however, this named list will be
returned, i.e., there are no side effects.
See setup.
gitignore
Logical. Only has an effect if the paths$projectPath
is a git repositories without submodules. This case is ambiguous what a user
wants. If TRUE, the default, then paths$modulePath will be added to
the .gitignore file. Can be controled with options(SpadES.project.gitignore = ...).
studyArea
Optional. If a list, it will be passed to
geodata::gadm. To specify a country other than the default "CAN",
the list must have a named element, "country". All other named elements
will be passed to gadm. 2 additional named elements can be passed for
convenience, subregion = "...", which will be grepped with the column
NAME_1, and epsg = "...", so a user can pass an epsg.io code to
reproject the studyArea. See examples.
Details
setPaths will fill in any paths that are not explicitly supplied by the
user as a named list. These paths that can be set are:
projectPath, packagePath, cachePath, inputPath,
modulePath, outputPath, rasterPath, scratchPath, terraPath.
These are grouped thematically into three groups of paths:
projectPath and packagePath affect the project, regardless
of whether a user uses SpaDES modules. cachePath, inputPath, outputPath and
modulePath are all used by SpaDES within module contexts. scratchPath,
rasterPath and terraPath are all "temporary" or "scratch" directories.
setupFunctions will source the functions supplied, with a parent environment being
the internal temporary environment of the setupProject, i.e., they will have
access to all the objects in the call.
Most arguments in the family of setup* functions are run sequentially, even within
the argument. Since most arguments take lists, the user can set values at a first
value of a list, then use it in calculation of the 2nd value and so on. See
examples. This "sequential" evaluation occurs in the ..., setupSideEffects, setupOptions,
setupParams (this does not work for setupPaths) can handle sequentially
specified values, meaning a user can
first create a list of default options, then a list of user-desired options that
may or may not replace individual values. This can create hierarchies, based on
order.
setupOptions can handle sequentially specified values, meaning a user can
first create a list of default options, then a list of user-desired options that
may or may not replace individual values. Thus final values will be based on the
order that they are provided.
setupModules will download all modules do not yet exist locally. The current
test for "exists locally" is simply whether the directory exists. If a user
wants to update the module, overwrite = TRUE must be set, or else the user can
remove the folder manually.
setupPackages will read the modules' metadata reqdPkgs element. It will combine
these with any packages passed manually by the user to packages, and pass all
these packages to Require::Install(...).
setupGitIgnore will add.
setupStudyArea only uses inputPath within its paths argument, which will
be passed to path argument of gadm. User can pass any named list element
that matches the columns in the sf object, including e.g., NAME_1 and, if level = 2,
is specified, then NAME_2.
setupStudyArea(list(NAME_1 = "Alberta", "NAME_2" = "Division No. 17", level = 2))
Value
setupPaths returns a list of paths that are created. projectPath will be
assumed to be the base of other non-temporary and non-R-library paths. This means
that all paths that are directly used by simInit are assumed to be relative
to the projectPath. If a user chooses to specify absolute paths, then they will
be returned as is. It is also called for its
side effect which is to call setPaths, with each of these paths as an argument.
See table for details. If a user supplies extra paths not useable by SpaDES.core::simInit,
these will added as an attribute ("extraPaths") to the paths element
in the returned object. These will still exist directly in the returned list
if a user uses setupPaths directly, but these will not be returned with
setupProject because setupProject is intended to be used with SpaDES.core::simInit.
In addition, three paths will be added to this same attribute automatically:
projectPath, packagePath, and .prevLibPaths which is the previous value for
.libPaths() before changing to packagePath.
setupFunctions returns NULL. All functions will be placed in envir.
setupSideEffects is run for its side effects (e.g., web authentication, custom package
options that cannot use base::options), with deliberately nothing returned to user.
This, like other parts of this function, attempts to prevent unwanted outcomes
that occur when a user uses e.g., source without being very careful about
what and where the objects are sourced to.
setupOptions is run for its side effects, namely, changes to the options(). The
list of modified options will be added as an attribute (attr(out, "projectOptions")),
e.g., so they can be "unset" by user later.
setupModules is run for its side effects, i.e., downloads modules and puts them
into the paths[["modulePath"]]. It will return a named list, where the names are the
full module names and the list elemen.ts are the R packages that the module
depends on (reqsPkgs)
setupPackages is run for its side effects, i.e., installing packages to
paths[["packagePath"]].
setupParams prepares a named list of named lists, suitable to be passed to
the params argument of simInit.
setupGitIgnore is run for its side effects, i.e., adding either paths$packagePath
and/or paths$modulePath to the
.gitignore file. It will check whether packagePath is located inside the
paths$projectPath and will add this folder to the .gitignore if TRUE.
If the project is a git repository with git submodules, then it will add nothing else.
If the project is a git repository without git submodules, then the paths$modulePath
will be added to the .gitignore file. It is assumed that these modules are
used in a read only manner.
setupStudyArea will return an sf class object coming from geodata::gadm,
with subregion specification as described in the studyArea argument.fsu
Paths
Path Default if not supplied by user Effects
Project Level Paths
projectPath if getwd() is name, then just getwd; if not
file.path(getwd(), name) If current project is not this project
and using Rstudio, then the current
project will close and a new project will
open in the same Rstudio session, unless
Restart = FALSE
packagePath file.path(tools::R_user_dir("data"), name, "packages", version$platform, substr(getRversion(), 1, 3))
appends this path to .libPaths(packagePath),
unless standAlone = TRUE, in which case,
it will set .libPaths(packagePath, include.site = FALSE) to this path
------ ----------- -----
Module Level Paths
cachePath file.path(projectPath, "cache") options(reproducible.cachePath = cachePath)
inputPath file.path(projectPath, "inputs") options(spades.inputPath = inputPath)
modulePath file.path(projectPath, "modules") options(spades.inputPath = outputPath)
outputPath file.path(projectPath, "outputs") options(spades.inputPath = modulePath)
------ ----------- -----
Temporary Paths
scratchPath file.path(tempdir(), name)
rasterPath file.path(scratchPath, "raster") sets (rasterOptions(tmpdir = rasterPath))
terraPath file.path(scratchPath, "terra") sets (terraOptions(tempdir = terraPath))
------ ----------- -----
Other Paths
logPath file.path(outputPath(sim), "log") sets options("spades.logPath") accessible by logPath(sim)
tilePath Not implemented yet Not implemented yet
Examples
## simplest case; just creates folders
out <- setupProject(
paths = list(projectPath = ".") #
)
# specifying functions argument, with a local file and a definition here
tf <- tempfile(fileext = ".R")
fnDefs <- c("fn <- function(x) x\n",
"fn2 <- function(x) x\n",
"fn3 <- function(x) terra::rast(x)")
cat(text = fnDefs, file = tf)
funHere <- function(y) y
out <- setupProject(functions = list(a = function(x) return(x),
tf,
funHere = funHere), # have to name it
# now use the functions when creating objects
drr = 1,
b = a(drr),
q = funHere(22),
ddd = fn3(terra::ext(0,b,0,b)))
PredictiveEcology/SpaDES.project documentation built on Dec. 23, 2024, 7:33 a.m.
R Package Documentation
Browse R Packages
We want your feedback!
Note that we can't provide technical support on individual packages. You should contact the package authors for that.
| setupPaths | R Documentation |
Individual setup* functions that are contained within setupProject
Description
These functions will allow more user control, though in most circumstances, it should be unnecessary to call them directly.
Usage
setupPaths(
name,
paths,
inProject,
standAlone = TRUE,
libPaths = NULL,
updateRprofile = getOption("SpaDES.project.updateRprofile", TRUE),
Restart = getOption("SpaDES.project.Restart", FALSE),
overwrite = FALSE,
envir = parent.frame(),
useGit = getOption("SpaDES.project.useGit", FALSE),
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
...
)
setupFunctions(
functions,
name,
sideEffects,
paths,
overwrite = FALSE,
envir = parent.frame(),
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
...
)
setupSideEffects(
name,
sideEffects,
paths,
times,
overwrite = FALSE,
envir = parent.frame(),
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
...
)
setupOptions(
name,
options,
paths,
times,
overwrite = FALSE,
envir = parent.frame(),
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
useGit = getOption("SpaDES.project.useGit", FALSE),
updateRprofile = getOption("SpaDES.project.updateRprofile", TRUE),
...
)
setupModules(
name,
paths,
modules,
inProject,
useGit = getOption("SpaDES.project.useGit", FALSE),
overwrite = FALSE,
envir = parent.frame(),
gitUserName,
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
updateRprofile = getOption("SpaDES.project.updateRprofile", TRUE),
...
)
setupPackages(
packages,
modulePackages = list(),
require = list(),
paths,
libPaths,
setLinuxBinaryRepo = TRUE,
standAlone,
envir = parent.frame(),
verbose = getOption("Require.verbose"),
dots,
defaultDots,
...
)
setupParams(
name,
params,
paths,
modules,
times,
options,
overwrite = FALSE,
envir = parent.frame(),
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
...
)
setupGitIgnore(
paths,
gitignore = getOption("SpaDES.project.gitignore", TRUE),
verbose
)
setupStudyArea(
studyArea,
paths,
envir,
verbose = getOption("Require.verbose", 1L)
)
Arguments
name |
Optional. If supplied, the name of the project. If not supplied, an
attempt will be made to extract the name from the |
paths |
a list with named elements, specifically, |
inProject |
A logical. If |
standAlone |
A logical. Passed to |
libPaths |
Deprecated. Use |
updateRprofile |
Logical. Should the |
Restart |
Logical or character. If either |
overwrite |
Logical vector or character vector, however, only |
envir |
An environment within which to look for objects. If called alone,
the function should use its own internal environment. If called from another
function, e.g., |
useGit |
(if not FALSE, then experimental still). There are two levels at which a project
can use GitHub, either the |
verbose |
Numeric or logical indicating how verbose should the function
be. If -1 or -2, then as little verbosity as possible. If 0 or FALSE,
then minimal outputs; if |
dots |
Any other named objects passed as a list a user might want for other elements. |
defaultDots |
A named list of any arbitrary R objects.
These can be supplied to give default values to objects that
are otherwise passed in with the |
... |
further named arguments that acts like |
functions |
A set of function definitions to be used within |
sideEffects |
Optional. This can be an expression or one or more file names or
a code chunk surrounded by |
times |
Optional. This will be returned if supplied; if supplied, the values
can be used in e.g., |
options |
Optional. Either a named list to be passed to |
modules |
a character string of modules to pass to |
gitUserName |
The GitHub account name. Used with git clone git@github.com:gitHuserName/name |
packages |
Optional. A vector of packages that must exist in the |
modulePackages |
A named list, where names are the module names, and the elements
of the list are packages in a form that |
require |
Optional. A character vector of packages to install and attach
(with |
setLinuxBinaryRepo |
Logical. Should the binary RStudio Package Manager be used on Linux (ignored if Windows) |
params |
Optional. Similar to |
gitignore |
Logical. Only has an effect if the |
studyArea |
Optional. If a list, it will be passed to
|
Details
setPaths will fill in any paths that are not explicitly supplied by the
user as a named list. These paths that can be set are:
projectPath, packagePath, cachePath, inputPath,
modulePath, outputPath, rasterPath, scratchPath, terraPath.
These are grouped thematically into three groups of paths:
projectPath and packagePath affect the project, regardless
of whether a user uses SpaDES modules. cachePath, inputPath, outputPath and
modulePath are all used by SpaDES within module contexts. scratchPath,
rasterPath and terraPath are all "temporary" or "scratch" directories.
setupFunctions will source the functions supplied, with a parent environment being
the internal temporary environment of the setupProject, i.e., they will have
access to all the objects in the call.
Most arguments in the family of setup* functions are run sequentially, even within
the argument. Since most arguments take lists, the user can set values at a first
value of a list, then use it in calculation of the 2nd value and so on. See
examples. This "sequential" evaluation occurs in the ..., setupSideEffects, setupOptions,
setupParams (this does not work for setupPaths) can handle sequentially
specified values, meaning a user can
first create a list of default options, then a list of user-desired options that
may or may not replace individual values. This can create hierarchies, based on
order.
setupOptions can handle sequentially specified values, meaning a user can
first create a list of default options, then a list of user-desired options that
may or may not replace individual values. Thus final values will be based on the
order that they are provided.
setupModules will download all modules do not yet exist locally. The current
test for "exists locally" is simply whether the directory exists. If a user
wants to update the module, overwrite = TRUE must be set, or else the user can
remove the folder manually.
setupPackages will read the modules' metadata reqdPkgs element. It will combine
these with any packages passed manually by the user to packages, and pass all
these packages to Require::Install(...).
setupGitIgnore will add.
setupStudyArea only uses inputPath within its paths argument, which will
be passed to path argument of gadm. User can pass any named list element
that matches the columns in the sf object, including e.g., NAME_1 and, if level = 2,
is specified, then NAME_2.
setupStudyArea(list(NAME_1 = "Alberta", "NAME_2" = "Division No. 17", level = 2))
Value
setupPaths returns a list of paths that are created. projectPath will be
assumed to be the base of other non-temporary and non-R-library paths. This means
that all paths that are directly used by simInit are assumed to be relative
to the projectPath. If a user chooses to specify absolute paths, then they will
be returned as is. It is also called for its
side effect which is to call setPaths, with each of these paths as an argument.
See table for details. If a user supplies extra paths not useable by SpaDES.core::simInit,
these will added as an attribute ("extraPaths") to the paths element
in the returned object. These will still exist directly in the returned list
if a user uses setupPaths directly, but these will not be returned with
setupProject because setupProject is intended to be used with SpaDES.core::simInit.
In addition, three paths will be added to this same attribute automatically:
projectPath, packagePath, and .prevLibPaths which is the previous value for
.libPaths() before changing to packagePath.
setupFunctions returns NULL. All functions will be placed in envir.
setupSideEffects is run for its side effects (e.g., web authentication, custom package
options that cannot use base::options), with deliberately nothing returned to user.
This, like other parts of this function, attempts to prevent unwanted outcomes
that occur when a user uses e.g., source without being very careful about
what and where the objects are sourced to.
setupOptions is run for its side effects, namely, changes to the options(). The
list of modified options will be added as an attribute (attr(out, "projectOptions")),
e.g., so they can be "unset" by user later.
setupModules is run for its side effects, i.e., downloads modules and puts them
into the paths[["modulePath"]]. It will return a named list, where the names are the
full module names and the list elemen.ts are the R packages that the module
depends on (reqsPkgs)
setupPackages is run for its side effects, i.e., installing packages to
paths[["packagePath"]].
setupParams prepares a named list of named lists, suitable to be passed to
the params argument of simInit.
setupGitIgnore is run for its side effects, i.e., adding either paths$packagePath
and/or paths$modulePath to the
.gitignore file. It will check whether packagePath is located inside the
paths$projectPath and will add this folder to the .gitignore if TRUE.
If the project is a git repository with git submodules, then it will add nothing else.
If the project is a git repository without git submodules, then the paths$modulePath
will be added to the .gitignore file. It is assumed that these modules are
used in a read only manner.
setupStudyArea will return an sf class object coming from geodata::gadm,
with subregion specification as described in the studyArea argument.fsu
Paths
| Path | Default if not supplied by user | Effects |
| Project Level Paths | ||
projectPath | if getwd() is name, then just getwd; if not
file.path(getwd(), name) | If current project is not this project
and using Rstudio, then the current
project will close and a new project will
open in the same Rstudio session, unless
Restart = FALSE |
packagePath | file.path(tools::R_user_dir("data"), name, "packages", version$platform, substr(getRversion(), 1, 3))
| appends this path to .libPaths(packagePath),
unless standAlone = TRUE, in which case,
it will set .libPaths(packagePath, include.site = FALSE) to this path |
| ------ | ----------- | ----- |
| Module Level Paths | ||
cachePath | file.path(projectPath, "cache") | options(reproducible.cachePath = cachePath) |
inputPath | file.path(projectPath, "inputs") | options(spades.inputPath = inputPath) |
modulePath | file.path(projectPath, "modules") | options(spades.inputPath = outputPath) |
outputPath | file.path(projectPath, "outputs") | options(spades.inputPath = modulePath) |
| ------ | ----------- | ----- |
| Temporary Paths | ||
scratchPath | file.path(tempdir(), name) | |
rasterPath | file.path(scratchPath, "raster") | sets (rasterOptions(tmpdir = rasterPath)) |
terraPath | file.path(scratchPath, "terra") | sets (terraOptions(tempdir = terraPath)) |
| ------ | ----------- | ----- |
| Other Paths | ||
logPath | file.path(outputPath(sim), "log") | sets options("spades.logPath") accessible by logPath(sim) |
tilePath | Not implemented yet | Not implemented yet |
Examples
## simplest case; just creates folders
out <- setupProject(
paths = list(projectPath = ".") #
)
# specifying functions argument, with a local file and a definition here
tf <- tempfile(fileext = ".R")
fnDefs <- c("fn <- function(x) x\n",
"fn2 <- function(x) x\n",
"fn3 <- function(x) terra::rast(x)")
cat(text = fnDefs, file = tf)
funHere <- function(y) y
out <- setupProject(functions = list(a = function(x) return(x),
tf,
funHere = funHere), # have to name it
# now use the functions when creating objects
drr = 1,
b = a(drr),
q = funHere(22),
ddd = fn3(terra::ext(0,b,0,b)))
R Package Documentation
Browse R Packages
We want your feedback!
Note that we can't provide technical support on individual packages. You should contact the package authors for that.
Embedding an R snippet on your website
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.