modulePathR/setupProject.R
setupModules.RdMaterialise the modules requested in setupProject() beneath
paths[["modulePath"]], optionally as git submodules.
setupModules(
name,
paths,
modules,
inProject,
useGit = getOption("SpaDES.project.useGit", FALSE),
overwrite = FALSE,
envir = parent.frame(),
callingEnv = sys.frame(-2),
gitUserName,
verbose = getOption("Require.verbose", 1L),
dots,
defaultDots,
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"
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.
a character vector 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.
For convenience, these can also be 2 other url formats:
the raw.githubusercontent.com url that points to the main module file or the folder e.g.,
"https://raw.githubusercontent.com/PredictiveEcology/Biomass_core/refs/heads/main/Biomass_core.R"
The github.com url used for cloning a git repository, with optional "@branch" specified:
"https://github.com/PredictiveEcology/Biomass_speciesParameters.git@development"
See setup.
A logical. If TRUE, then the current directory is
inside the paths[["projectPath"]].
(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 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.
The GitHub account name. Used with git clone git@github.com:gitHuserName/name
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.
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.
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)
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.
setupProject() for the high-level wrapper, setup_family for an overview.