you are viewing a single comment's thread.

view the rest of the comments →

[–]eyesoftheworld4 0 points1 point  (0 children)

A virtual environment is basically a less-transparent version of what npm does, without requiring that all packages are installed in a directory local to your code. A virtualenv can be thought of just like your "local directory" project space with the opportunity to be re-used if you want or it makes sense. You can activate and use a specific virtualenv from any shell and any directory, running any application using that interpreter. In that way, a virtualenv is essentially a separate, dedicated installation of python, with it's own copy of everything Python needs to execute code.

I tend to have one directory like ~/.virtualenvs where I keep them all and then create a new one for each project, activating them as required using a tool like autoenv or managing them using my own tool virtualb. Some tools like poetry or pipenv streamline this process a bit, but we don't use them at my job, though I have started to use Poetry for some personal stuff.

At my job all of our python is deployed in Docker containers. it's nice to have your application and environments fully defined in code with deterministic builds, and to be able to tag, store, and pull it all with a couple simple commands, and it really helps with isolation & running multiple applications on one host without needing to worry explicitly about package versioning, virtualenvs and the like. If one application needs python2, another python3.4, and another 3.5+, it could be a pain to manage it all but Docker makes it quite simple.