Brodriguez: Brodriguez moved page Python/Setup to Programming/Python/Setup

2020-10-31T06:21:05Z

Brodriguez moved page Python/Setup to Programming/Python/Setup

← Older revision

Revision as of 06:21, 31 October 2020

Brodriguez: Create page

2020-10-31T06:14:54Z

Create page

New page

== Installation ==

=== Arch Linux ===

=== Ubuntu ===

=== Windows ===

== Virtual Environments ==
In Python, {{ ic |Virtual Environments}} are a way to separate Python package installations, in order to prevent conflicts between different project setups.

=== Environment Setup ===
As of 2020, there are two recommended ways to setup Virtual Environments.

==== Venv ====
The {{ ic |venv}} package is shipped with Python3 on windows. It also ships with some Python3 distributions on Linux systems.

{{ ToDo | link to above for install? }}

To create a new environment, use:
python<version> -m venv <path_to_create_environment_at>

For example, if you wanted a Python3.5 environment called '''MyEnv''' in your local user home directory, then use:
python3.5 -m venv ~/MyEnv

==== Virtualenv ====
Virtualenv is a third party package that's officially supported by the PyPA (Python Packaging Authority).

First, install with:
pip install virtualenv

To createa new environment, use:
virtualenv --python=python<version> <path_to_create_environment_at>

For example, if you wanted a Python3.5 environment called '''MyEnv''' in your local user home directory, then use:
virtualenv --python=3.5 ~/MyEnv

=== Using Virtual Environments ===
Regardless of which above method you used to install the environment, you load them the same way.

{{ note | In most OS's, it display in console on every line, when a Python environment is loaded. You can further verify an environment has loaded via the {{ ic |which python}}, {{ ic |which pip}}, {{ ic |python -V}}, and {{ ic |pip -V}} commands.}}

==== Linux/Mac ====
To load an environment, use:
source <path_to_environment>/bin/activate

Ex:
source ./my_env/bin/activate

To unload an environment, use:
deactivate

==== Windows ====
To load an environment, use:
. <path_to_environment>/Scripts/activate

Ex:
. <path_to_environment>/Scripts/activate

=== 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.

==== An Environment for Each Project ====
This method involves creating an environment (usually labeled {{ ic |.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 environments on directory change. See https://git.brandon-rodriguez.com/python/example_projects/virtual_environments.

==== Multiple Environments in a Central Location ====
This method involves creating all your virtual environments in a single location (for example, {{ ic |~/Env/}}).

For example, you might have {{ ic |~/Env/Django2.0}}, {{ ic |~/Env/wxPython}}, and {{ ic |~/Env/Django3.0}}.

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.

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. {{ todo | link to commands }}

Programming/Python/Setup - Revision history

Brodriguez: Brodriguez moved page Python/Setup to Programming/Python/Setup

Brodriguez: Create page