Set the options() supplied to setupProject() and record the prior values
so they can be restored.
setupOptions(
name,
options,
paths,
times,
overwrite = FALSE,
envir = parent.frame(),
callingEnv = sys.frame(-2),
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
useGit = getOption("SpaDES.project.useGit", FALSE),
updateRprofile = getOption("SpaDES.project.updateRprofile", TRUE),
...
)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"
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.
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.
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.
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 – including those downloaded via sideEffects.
If a length > 1 logical or character vector, these will be passed to getModule: only the named
modules will be overwritten or the logical vector of the modules.
NOTE: if length > 1, no other file specified anywhere in setupProject will be
overwritten except a module matching the vector 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.
The environment where setupProject is called from. Defaults to
parent.frame() which should be fine in most cases and user shouldn't need
to set this
The environment from which the function was called. Defaults to sys.frame(-2)
which represents the case where the inner setup* functions are called inside
setupProject, which was called by a user.
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).
Any other named objects passed as a list a user might want for other elements.
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.
(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).
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.
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.
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.
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.
setupProject() for the high-level wrapper, setup_family for an overview.