Configuration¶
Environment variables¶
Anaconda Project has modifiable configuration settings, which are currently controlled exclusively by environment variables.
ANACONDA_PROJECT_DISABLE_OVERRIDE_CHANNELS
- Starting in version 0.11.0 Anaconda Project ignores any CondaRC
configuration settings for
channels:
by default. Packages will only be installed from channels listed in theanaconda-project.yml
file. Set this environment variable to a true value (1, or'True'
) to disable the override and allow the user or global CondaRC configuration to control channels from which Anaconda Project can install packages. ANACONDA_PROJECT_ENVS_PATH
This variable provides a list of directories to search for environments to use in projects, and where to build them when needed. The format is identical to a standard
PATH
variable on the host operating system—a list of directories separated by:
on Unix systems and;
on Windows—except that empty entries are permitted. The paths are interpreted as follows:- If a path is empty, it is interpreted as the default value
envs
. - If a path is relative, it is interpreted relative to the root directory
of the project itself (
PROJECT_DIR
). For example, a path entryenvs
is interpreted as$PROJECT_DIR/envs
(Unix)%PROJECT_DIR%\envs
(Windows)
- When searching for an environment, the directories are searched in left-to-right order.
- If an environment with the requested name is found nowhere in the path, one will be created as a subdirectory of the first entry in the path.
For example, given a Unix machine with
ANACONDA_PROJECT_ENVS_PATH=/opt/envs::envs2:/home/user/conda/envs
Then Anaconda Project will look for an environment named
default
in the following locations:/opt/envs/default
$PROJECT_DIR/envs/default
$PROJECT_DIR/envs2/default
/home/user/conda/envs/default
If no such environment exists, one will be created as
/opt/envs/default
, instead of the default location of$PROJECT_DIR/envs/default
.- If a path is empty, it is interpreted as the default value
ANACONDA_PROJECT_READONLY_ENVS_POLICY
When an
anaconda-project.yml
specifies the use of an existing environment, but that environment is missing one or more of the requested packages, Anaconda Project attempts to remedy the deficiency by installing the missing packages. If the specified environment is read-only, however, such an installation would fail. The value of the environment variableANACONDA_PROJECT_READONLY_ENVS_POLICY
governs what action should be taken in such a case.fail
- The attempt will fail, and a message returned indicating that the requested changes could not be made.
clone
- A clone of the read-only environment will be made, and additional packages will be installed into this cloned environment. Note that a clone will occur only if additional packages are required.
replace
- An entirely new environment will be created.
If this environment variable is empty or contains any other value than these, the
fail
behavior will be assumed. Note that forclone
orreplace
to succeed, a writable environment location must exist somewhere in theANACONDA_PROJECT_ENVS_PATH
path.
Read-only environments¶
On some systems, it is desirable to provide Anaconda Project access to one or more read-only environments. These environments can be centrally managed by administrators, and will speed up environment preparation for users that elect to use them.
On Unix, a read-only environment is quite easy to enforce with standard POSIX permissions settings. Unfortunately, our experience on Windows systems suggests it is more challenging to enforce. For this reason, we have adopted a simple approach that allows environments to be explicitly marked as read-only with a flag file:
- If a file called
.readonly
is found in the root of an environment, that environment will be considered read-only. - If a file called
.readonly
is found in the parent of an environment directory, the environment will be considered read-only. - An attempt is made to write a file
var/cache/anaconda-project/status
within the environment, creating the subdirectories as needed. If successful, the environment is considered read-write; otherwise, it is considered read-only.
This second test is particularly useful when centrally managing and entire
directory of environments. With a single .readonly
flag file, all new
environments created within that directory will be treated as read-only.
Of course, for the best protection, POSIX or Windows read-only permissions
should be applied nevertheless.