diff --git a/readme.md b/readme.md index 2f1c80ce6c9ec0762e63818235063810567391bf..bc5c14ca1fcc82adc39cd3b88fdc22a80f9f594d 100644 --- a/readme.md +++ b/readme.md @@ -15,68 +15,90 @@ folders. Virtual Environments are a way to separate Python package installations, in order to prevent conflicts between different project setups. -Through Virtual Environments, you can also easily access different Python versions between different projects. +### Environment Setup +As of 2020, there are two recommended ways to setup Virtual Environments: `venv` or `virtualenv`. -For example, you could have a Python3.7 installation for Django, a Python3.5 installation for wxPython, and a Python2.7 -installation for general script usage. +#### Venv +The venv package is shipped with Python3 on windows. It also ships with some Python3 distributions on Linux systems. -As of writing this, there are two recommended ways to setup Virtual Environments: the `virtualenv` Python package or the -`venv` package. +For full details on installation, see https://wiki.brandon-rodriguez.com/Programming/Python/Setup. -### Venv -The `venv` package is generally shipped with Python3, although some OS distros separate it into a distro package (for -example, on Ubuntu, install with `apt install python3-venv`). +To create a new environment, use: -This method will only work with Python version 3 or higher. + python<version> -m venv <path_to_create_environment_at> - * To use, call `python<version> -m venv </path/to/new/virtual/environment>`. - * Ex: `python3.5 -m venv ./my_environment` +Ex: -### Virtualenv + `python3.5 -m venv ./my_environment` + +#### Virtualenv Virtualenv is a third party package that's officially supported by the PyPA (Python Packaging Authority). -This method can be used on any Python version. +First, install with: + + pip install virtualenv + +To create a new environment, use: - * First, install with `pip install virtualenv`. - * To use, call `virtualenv --python=python<verion> </path/to/new/virtual/environment>`. - * Ex: `virtualenv --python=3.5 ./my_environment` + virtualenv --python=python<verion> <path_to_create_environment_at> + +Ex: + + virtualenv --python=3.5 ./my_environment ## Using Virtual Environments -Either of the above methods should essentially provide the same result. +Regardless of which above method you used to install the environment, you load them the same way. + + In most OS's, it display in console on every line, when a Python environment is loaded. You can verify the environment loaded through the `which python`, `which pip`, `python -V`, and `pip -V` commands. + + +### Linux/Mac +To load an environment, use: + + source </path_to_environment>/bin/activate + +Ex: + + source ./my_env/bin/activate -* Linux/Mac: - * To load an environment, use `source </path/to/environment>/bin/activate`. - * Ex: `source ./my_env/bin/activate` - * When successfully loaded, the console will generally display the name of the environment. - * To unload an environment, use `deactivate`. - * When successfully unloaded, the console will no longer display the name of the environment. +To unload an environment, use -* Windows: - * To load an environment, use `. <path/to/environment>/Scripts/activate`. - * Ex: `. ./my_env/Scripts/activate` - * To unload an environment, use `deactivate`. + deactivate + +### Windows +To load an environment, use: + + . <path_to_environment>/Scripts/activate + +* Ex: + `. ./my_env/Scripts/activate` + +To unload an environment, use + + deactivate -You can verify the environment loaded through the `which python`, `which pip`, `python -V`, and `pip -V` commands. ## Organizing Virtual Environments -There are two general practices for organizing virtual environments. +There are two general practices for organizing Virtual Environments. Generally speaking, most prefer the first option, +which creates a new environment for each project. -Generally speaking, most prefer to use the second option, which creates a new environment for each project. +### An Environment for Each Project +This method involves creating an environment (usually labeled `.venv`) at the root of every project. + +This keeps all of your dependencies isolated for every project, which is particularly useful for mimicking and testing +production setups. + +Furthermore, it's possible to set up your console to automatically load these environment on directory change (see +attached helper script). ### Multiple Environments in a Central Location This method involves creating all your virtual environments in a single location (for example, `~/Env/`). -For example, you might have `~/Env/Django2.1`, `~/Env/wxPython`, and `~/Env/Django1.8`. +For example, you might have `~/Env/Django2.0`, `~/Env/wxPython`, and `~/Env/Django3.0`. -The benefit of this method is that you can reuse the same environment for multiple different projects. However, there is -no way to get the console to automatically import your desired environment. You'll have to manually select it with the -above commands. - -### An Environment for Each Project -This method involves creating an environment (labeled `.venv`) at the root of every project. +The benefit of this method is that you can reuse the same environment for multiple different projects, which results in +less time setting up and maintaining environments. -For example, you might have `/my_project/.venv`, and would repeat for every Python project. +However, you might get package conflicts between projects. Furthermore, there is no way to have the console to +automatically import your desired environment. You'll have to manually select it with the above commands. -The benefit of this method is that you can set up your console to automatically load the environment on cd (see attached -helper script). However, if you have multiple projects that use the same packages, you'll still need to create separate -environments for each one.