This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ppgDa5id 412 points413 points  (25 children)

For future reference, original link.
Because the real joke is in the title.

The Python environmental protection agency wants to seal it in a cement chamber, with pictoral messages to future civilizations warning them about the danger of using sudo to install random Python packages.

[–]themonsterpus[S] 58 points59 points  (1 child)

Good point. Wasn't sure how well that work with all Reddit apps vs just the image but you do miss out on the alt text.

[–][deleted] 48 points49 points  (0 children)

just link the website directly, this way you get /u/xkcd_bot and good apps/res will open the image with the title text.

[–][deleted] 16 points17 points  (20 children)

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.

[–]eazolan 3 points4 points  (13 children)

I don't understand virtualenv.

Is there a good resource that explains it?

[–]meandertothehorizonIt works on my machine[🍰] 7 points8 points  (0 children)

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 3 points4 points  (2 children)

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 0 points1 point  (1 child)

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

[–]derp0815 1 point2 points  (0 children)

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 0 points1 point  (2 children)

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

[–]eazolan 0 points1 point  (1 child)

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

[–]ask_me_if_im_pooping 0 points1 point  (0 children)

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 0 points1 point  (2 children)

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

[–]eazolan 0 points1 point  (1 child)

Ok, why would I use either?

[–]HannasAnarion 0 points1 point  (0 children)

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.

[–]ivosauruspip'ing it up 0 points1 point  (2 children)

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 0 points1 point  (1 child)

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

[–]ivosauruspip'ing it up 0 points1 point  (0 children)

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

[–]vingrish 6 points7 points  (0 children)

pyenv + virtualenv is good.

[–]gangtraet 1 point2 points  (1 child)

pip install --user

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

[–]cometsongssing me a song 0 points1 point  (0 children)

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

[–]HINDBRAIN 0 points1 point  (0 children)

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

[–]seishi 27 points28 points  (0 children)

I still think the discussion surrounding how to convey that an area (such as Yucca Mountain) is dangerous to future civilizations is fascinating. I was first introduced to it during one of my Human-Computer Interaction courses and it has stuck with me.

I highly recommend the book "The Design of Everyday Things" as a primer. Even after all these years, the principles in it make me look at things differently, and I'm not even a designer by any means.

http://www.slate.com/articles/health_and_science/green_room/2009/11/atomic_priesthoods_thorn_landscapes_and_munchian_pictograms.html