Add how-to guides for setting up a python venv

[gcapes]

Before I do this, I just wanted to check whether there is any policy/preference as to whether this is done with venv or conda?

• Why use virtual environments?
• How to create and activate a virtual environment
• How to install packages with pip from pypi
• How to install a local package for development (editable)
• Using a requirements file

Though having looked through the wiki a bit more, it seems some of this already exists, but a bit buried, and pretty conda-leaning:
https://lightform-group.github.io/wiki/software_and_simulation/install-dev-version
https://lightform-group.github.io/wiki/software_and_simulation/developing-python-packages#installing-our-package-in-editable-mode

[gcapes]

I had a bit of a pip/venv vs conda discussion with @samuel-hg-engel and @Gbowker

I think the main requirements are:

• Agree on one approach to recommend. Those who have opinions/experience will figure out how to apply the recommendations to their preferred virtual environment/package installation approach. CSF3 docs recommend conda, and are maintained so just linking to them would reduce the maintenance burden for this wiki. That said CSF3 docs are generally written by sys admins rather than by programmers who use the software regularly, so maybe aren't the best reference point?
• Use a virtual environment to explicitly install packages for a project rather than installing into the "base" environment which, especially if using conda, will have lots of packages already installed that you don't need. This is a good approach for reproducibility which also makes it easier for other people to help you (as you'll have a requirements.txt file or conda equivalent in your repo).
• Packages available. My experience is that packages are often not available to install using conda. MatFlow is one such package. The usual go-to solution for this is to pip install into your conda environment. Why not just use venv + pip to start with?
• Clarity of use. By default conda installs environments somewhere central like ~/.conda/envs. You then have to remember which environment goes with which project. python -m venv .venv installs to wherever you explicitly choose (for me this is in the project directory) so it should be obvious that this environment is for the project which contains it. The conda docs suggest activating the conda virtual env using conda activate, whereas a different command is needed on CSF3 source activate. Activating a venv is the same command source .venv/bin/activate

I don't have a lot of experience with conda, but I think one of its strengths is simplifying non-python software installations. If you're only using conda for python, this doesn't really factor into the decision.

[samuel-hg-engel]

I just wanted to add to the clarity of use point, in conda you can specifiy conda create -p myenv which creates the enviroment in any specific location, which can then be activated by sourcing the absolute filepath to the enviroment.