[Chapter 2.2] virtualenvwrapper recommendation might not be a good practice

[pszpetkowski]

In the first place I'd like to thank the authors and all the contributors of this book - it's awesome.

You could say that virtualenvwraper is quite useful as it makes the programmer type and think less. I believe that it's very shallow convenience and in few points I'll do my best to explain why:

• virtualenvwrapper doesn't work with all shells (e.g. fish shell)
• since Python 3.3 there is rarely used, but awesome venv module, which might be better than virtualenv.
• virtualenvwrapper might be really awful solution for some configurations e.g. imagine a case in which you need to keep everything related to a project (including 3rd party modules) in a single directory and you have few of such projects under one user. There is only one WORKON_HOME variable, which will point to only one directory.
• Some coding tools automatically detect if there is a Python virtual environment in the project tree, so that makes virtualenvwrapper redundant for some projects.

Major downside of venv is that it isn't available with Python < 3.3 and the ensurepip mechanism has been added in Python 3.4, so for quite some people (e.g. those who wish for supported Python versions parity with virtualenv) it might not be a good choice, but I think that it's worthy to at least describe the venv as an alternative to virtualenv/virtualenvwrappper.