Avoiding dependency hell, the Python way
New developers might be tempted to install every interesting package that they come across. In doing so, they might realize that this quickly degrades into a Kafkaesque situation where previously installed packages may cease to function and newly installed packages may behave unpredictably, if they manage to get installed successfully at all. The problem with the preceding approach, as some of you may have guessed, is that of conflicting package dependencies. Say for example, we have package A installed; it depends on version 1 of package Q and version 1 of package R. Package B depends on version 2 of package R (where versions 1 and 2 are not API-compatible). Pip will happily install package B for you, which will upgrade package R to version 2. This will, at best, make package A completely unusable or, at worst, make it behave in undocumented and unpredictable ways.
The Python ecosystem has come up with a solution to the basic issues that arise from what is colloquially referred to as dependency hell. While far from perfect, it allows developers to sidestep many of the simplest package version dependency conflicts that can arise in web application development.
The virtualenv tool, of which a similar implementation is now a default module in Python 3.3 and named venv, is essential to ensure that you minimize your chances of ending up in dependency hell. The following quote is from the introduction in the official documentation for virtualenv:
It creates an environment that has its own installation directories, that doesn't share libraries with other virtualenv environments (and optionally doesn't access the globally installed libraries either).
More concisely, virtualenv allows you to create isolated environments for each one of your Python applications (or any Python code).
Note
The virtualenv tool does not, however, help you to manage the dependencies of the Python C-based extensions. For example, if you install the lxml package from pip, it will require that you have the correct libxml2 and libxslt system libraries and headers (which it will link against). The virtualenv tool will not help you isolate these system-level libraries.
