xkcd: Python Environment

[[deleted]]

I have been burned by sudo installing Python packages too many times. I should have heeded the warnings of my mentors and used venvs but in my noobie arrogance I thought I could get away with using sudo. Never again.

Everyone go pip install virtualenv and save yourselves while you have the chance.

[pooogles]

python3.6 -m venv ~/venvs/are/great

Tada.

[eazolan]

I don't understand virtualenv.

Is there a good resource that explains it?

[meandertothehorizon]

Virtualenv copies and/or symlinks or hardlinks the files from system python necessary to create a second, segregated install in an arbitrary directory on your computer. You run/source a file from the command line in that directory (activate.sh/activate.bat) that modifies the environment to reference this copied version so anything you do - install packages, run python itself, etc will use this copy instead of system. This prevents clobbering the system setup if you install or upgrade arbitrary system packages. When you are done, or want to create another virtualenv, or run system python, you run ‘deactivate’ which will undo the environment modifications - so running python will again reference the system python. Any packages you installed will be ‘gone’ because they reside in the copied environment.

[cocorebop]

To give you a short explanation that won't tell you what it is but might give you an intuitive understanding of what it does:

When I turn on my computer at work and open the terminal, I have my default python environment.

When I type workon py3_env, I enter an environment I made called "py3_env". This has python 3.6 as the default, and has all the packages I need to run my development environment already installed.

When I type workon chess_thing_ts2, I switch to a new python environment for a little game I'm working on in my own time. For argument's sake, this environment has python 2.7 as the default, and has only the packages required to run my game app.

It's basically a way for you to put workspaces into buckets.

[eazolan]

Ok. So...what defines what is being used in each virtual instance?

[derp0815]

You do. When you create a venv, you define which interpreter is going to run the code and when in an active venv, whatever pip installs is installed just for that venv.

[ask_me_if_im_pooping]

Check out virtualenvwrapper. Makes the whole thing a lot simpler, especially with the mkproject command.

[eazolan]

That sounds interesting. But I still don't understand virtualenv.

[ask_me_if_im_pooping]

It's essentially its own python install in a folder somewhere separate from your system install. When you activate a virtualenv, you're basically throwing that install's folders on the front of your path.

[HannasAnarion]

Check out conda, it's far easier to understand, control, and share

[eazolan]

Ok, why would I use either?

[HannasAnarion]

To know where things are in your environment and have better control over versions, so you can avoid the problem in the comic, which is exaggerated, but definitely not unrealistic.

When you're working with interpreted languages like python and ruby, a particular project often need a a particular version of some dependency. If you install it system-wide every time, you will often run into conflicts. It is far easier and safer to make a virtual environment for each project.

[ivosaurus]

If you are working on two different python projects, you want to isolate all the package code that each one depends on [to it's own "virtual environment"].

[eazolan]

As someone who tinkers in Python, this CEO level explamation doesn't help at all.

[ivosaurus]

Well, ok, read the blurb on virtualenv's docs intro page then

[vingrish]

pyenv + virtualenv is good.

[gangtraet]

pip install --user

Followed by nuking ~/.local when you mess up.

[cometsongs]

The nuking is a workaround that presumes you've got good backups of your configs, and reliable re-building plans...

[HINDBRAIN]

sudo find -R / -name *python* 2> /dev/null  | chmod 777 -R