conda_ops_dev_install.sh failing on miniconda3 docker image

[sroet]

since 467968c my CI started failing with:

CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
To initialize your shell, run
    $ conda init <SHELL_NAME>
Currently supported shells are:
  - bash
  - fish
  - tcsh
  - xonsh
  - zsh
  - powershell
See 'conda init --help' for more information and options.
IMPORTANT: You may need to close and restart your shell after running 'conda init

It is running the following script (which used to be the advised way of installing):

- conda install -y curl
- curl -OLk https://raw.githubusercontent.com/openpathsampling/openpathsampling/master/devtools/conda_ops_dev_install.sh
- OPS_ENV=py37 CONDA_PY="3.7" source conda_ops_dev_install.sh

and it is a known issue that activating conda inside docker containers can be tricky.

I can fix this on my CI by prerunning:

- conda init
- source $HOME/.bashrc

but I wanted to mention it here as well, in case someone else runs into this.
And to ask if we want to fix this on this side as well.

[dwhswenson]

Parent commit to 467968c is 8ccc108. Here's the CI run for that. It fails with:

devtools/conda_install_reqs.sh: line 65: activate: No such file or directory

Apparently source activate doesn't work, perhaps because of some difference in the setup for using the mambaforge variant in the setup-miniconda action. This is the reason I switched to conda activate.

I don't think this is something we can fix on the OPS side, although I'm open to solutions if you can find one. conda_ops_dev_install.sh (which then calls conda_install_reqs.sh) has two main use cases: (1) setting up CI for dependent packages; (2) facilitating developer installs to confirm bug fixes for users. In case (2), we don't want to re-initialize a user's conda setup. I think it's better to trust that the users in case (1) can figure out how to get their CI environment to work correctly with conda.

FWIW, while I was working on #1072 / #1073 (where those commits came from) I considered making significant changes to the conda_ops_dev_install.sh script. That script dates back to before OPS 1.1, where we made OPS pip-installable. Back then, the correct instructions for installing OPS as a dev install were "install conda, then install this list of requirements, then do a developer install of OPS" (and in practice we assumed the requirements didn't change, so we did a conda-install of OPS followed by an uninstall/dev install). These scripts shortened the process to "install conda; download and run this script" -- much easier both for CI and (especially) for novice users who need to test a bugfix (and probably already had conda installed.)

That script installs the things we use in testing OPS (including OpenMM, OpenMMTools, PLUMED, etc). This is more than is needed for bugfix users (or even users installing for integration testing in CI). I think a new dev install script that installed the minimum requirements would be reasonable (with that becoming recommended as we phase out the current scripts.) The current conda_install_reqs.sh should probably be kept for our own CI, though.

[sroet]

I don't think this is something we can fix on the OPS side, although I'm open to solutions if you can find one.

Reading through the usecases, I also don't think we can fix this for every usecase

In case (2), we don't want to re-initialize a user's conda setup. I think it's better to trust that the users in case (1) can figure out how to get their CI environment to work correctly with conda.

Seems fair.

Will close this and users running into this error on their CI should (hopefully) find this issue. The solution for my CI was running

- conda init
- source $HOME/.bashrc

before

source conda_ops_dev_install.sh