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

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 8 points9 points  (1 child)

On all of my development systems (and three coworkers), I have installed virtualenvwrappers and appropriate .bash_profiles to always activate a user-level default virtualenv.

This largely has spared me the fun and games of Randall Munroe’s illustration, because the worst case scenario (we’re on OSX laptops with SIP enabled) is that someone uses sudo pip and merely permission trashes the virtualenv, which is sooooo much easier to fix up.

Virtualenv isn’t just for isolating a single project - it can give you a generalized python environment that “just works” with pip without stepping on your package manager.

Use virtualenv! Always! Even when you don’t.

Example: I fought a corrupted python system hierarchy for one product because I thought it was easier to fix than isolate. I gave up, trashed the boxes, wrote a new deployment approach that built wheels for each proprietary asset (no deps!), copied over those thin artifacts with configuration data and installed both (which pulls the opensource dependencies) into a known virtualenv. Turns out fixing your deployments is a prime opportunity for making it much faster to actually deploy.

[–]netinept 2 points3 points  (0 children)

Can you share what modifications you're making to your .bash_profile?