tar_config_projects.Rd

% Generated by roxygen2: do not edit by hand
% Please edit documentation in R/tar_config_list.R
\name{tar_config_projects}
\alias{tar_config_projects}
\title{List projects.}
\usage{
tar_config_projects(config = Sys.getenv("TAR_CONFIG", "_targets.yaml"))
}
\arguments{
\item{config}{Character of length 1, file path of the YAML
configuration file with \code{targets} project settings.
The \code{config} argument specifies which YAML configuration
file that \code{tar_config_get()} reads from or \code{tar_config_set()}
writes to in a single function call.
It does not globally change which configuration file is used
in subsequent function calls. The default file path of the YAML
file is always \verb{_targets.yaml} unless you set another
default path using the \code{TAR_CONFIG} environment variable,
e.g. \code{Sys.setenv(TAR_CONFIG = "custom.yaml")}. This also has the
effect of temporarily modifying the default arguments to other functions
such as \code{\link[=tar_make]{tar_make()}} because the default arguments
to those functions are controlled by \code{tar_config_get()}.}
}
\value{
Character vector of names of projects defined in \verb{_targets.yaml}.
}
\description{
List the names of projects defined in \verb{_targets.yaml}.
}
\section{Storage access}{

Several functions like \code{tar_make()}, \code{tar_read()}, \code{tar_load()},
\code{tar_meta()}, and \code{tar_progress()} read or modify
the local data store of the pipeline.
The local data store is in flux while a pipeline is running,
and depending on how distributed computing or cloud computing is set up,
not all targets can even reach it. So please do not call these
functions from inside a target as part of a running
pipeline. The only exception is literate programming
target factories in the \code{tarchetypes} package such as \code{tar_render()}
and \code{tar_quarto()}.
}

\section{Configuration}{

For several key functions like \code{\link[=tar_make]{tar_make()}}, the
default values of arguments are controlled though
\code{tar_config_get()}. \code{tar_config_get()} retrieves data
from an optional YAML configuration file.
You can control the settings in the YAML
file programmatically with \code{tar_config_set()}.
The default file path of this YAML file is \verb{_targets.yaml}, and you can
set another path globally using the \code{TAR_CONFIG}
environment variable. The YAML file can store configuration
settings for multiple projects, and you can globally
set the default project with the \code{TAR_PROJECT} environment
variable.
The structure of the YAML file
follows rules similar to the \code{config} R package, e.g.
projects can inherit settings from one another using the \code{inherits} field.
Exceptions include:
\enumerate{
\item There is no requirement to have a configuration named \code{"default"}.
\item Other projects do not inherit from the default project` automatically.
\item Not all fields need values because \code{targets} already has defaults.
}

\code{targets} does not actually invoke
the \code{config} package. The implementation in \code{targets}
was written from scratch without viewing or copying any
part of the source code of \code{config}.
}

\examples{
yaml <- tempfile()
tar_config_set(store = "my_store_a", config = yaml, project = "project_a")
tar_config_set(store = "my_store_b", config = yaml, project = "project_b")
tar_config_projects(config = yaml)
}
\seealso{
Other configuration: 
\code{\link{tar_config_get}()},
\code{\link{tar_config_set}()},
\code{\link{tar_config_unset}()},
\code{\link{tar_config_yaml}()},
\code{\link{tar_envvars}()},
\code{\link{tar_option_get}()},
\code{\link{tar_option_reset}()},
\code{\link{tar_option_set}()},
\code{\link{tar_option_with}()}
}
\concept{configuration}