Support read-only environment management

[mcg1969]

anaconda-project supports the ability for projects to depend on read-only environments. The behavior when an environment with the given name deviates from the requirements of the project is controlled by the variable ANACONDA_PROJECT_READONLY_ENVS_POLICY:

• fail: the attempt to install/activate the project fails.
• replace: a brand new environment is created, and the existing environment is ignored.
• clone: the existing environment is cloned to a read-write location, and is then updated to meet the requirements of the project.

AEDSP depends on this behavior, hardcoded to clone mode, to allow administrators to provide a library of centrally managed environments for projects to depend upon. This capability depends closely on #121 as well for obvious reasons.

More information here: https://anaconda-project.readthedocs.io/en/latest/config.html

The relevant code is here: https://github.com/Anaconda-Platform/anaconda-project/blob/master/anaconda_project/requirements_registry/providers/conda_env.py#L207-L227

[AlbertDeFusco]

Thanks for the issue. Currently is_consistent checks for an exact match between the installed env and the lock spec.

This looks like an opportunity to support something like satisfies. Would you want something a little looser than is_consistent where the read-only env may have additional packages than is required by the lockspec? And must the installed packages be an exact match down to the sha256/md5 hash?

[mcg1969]

@AlbertDeFusco I don't really know how to answer your questions, because I don't use conda project, so I'm not sufficiently familiar with its approach. What I want is the functionality we currently have in anaconda-project. If there is more than that in conda-project, that is fine.

[mcg1969]

I have a feeling you are trying harder to keep things "locked" than anaconda-project does, and that is going to cause considerable difficulties with the way AE5 works. Locks are for production, IMO.