Closed nichollsh closed 2 months ago
I'm personally in favour of trying to avoid anaconda completely. Pip+venv based installs tend to be much simpler (to use, teach, and develop). Although sometimes you can't get around anaconda, depending if we need to distribute compiled code, or rely on packages that are not available through our system's package managers (e.g. petsc).
General consensus seems to be to move towards pypi+venv as the main "supported" method.
Seems that one disadvantage of venv is that you are limited to the version of python installed by the system's package manager. This is problematic if this version is not supported by PROTEUS. We should therefore ensure that conda-based installations still function, even if venv is the ideal method.
e.g. on the Oxford cluster the Python version is 3.8.10, which isn't supported by PROTEUS since it is lacking some of the required features.
That depends a bit on what options they give you to install your own version. There are many ways/tools to get python on your system:
Afterwards its just variations of ./path/to/python.exe -m venv .venv
(even if you use conda to get python).
Fair enough. pyenv
is new to me and looks very promising for cases where the user does not have root access on the machine. Regardless, I suppose it's too much for the PROTEUS documentation to account for all the possible ways that the user might want to install Python.
I will create a branch which simply updates the documentation to instead outline the setup of a venv and installation of required libraries with pip.
My IT department has recently discovered that some parts of the Anaconda software are no longer free as they have changed their licensing. This applies to the default conda channel, and therefore also to miniconda. Any organisation which has more that 200 employees, even universities and even for research need to pay for a licence which is in the region of $50 per person per month.
You can read about this here: https://www.anaconda.com/blog/is-conda-free https://legal.anaconda.com/policies/en/
It does not apply to conda-forge. https://conda-forge.org/blog/2020/11/20/anaconda-tos/
I have therefore been asked to immediately discontinue all use of conda, and instead use miniforge or venv+pip. I don't know how this applies to other organisations and their specific cases.
Switching to miniforge is pretty simple and might only require modifying the documentation to nudge the user towards it instead of miniconda.
@stefsmeets @lsoucasse what do you think?