【virtualenv】
用Python开发时面临的一个大问题就是每个项目需要的依赖包不一致。如果是包本身不一样倒还好，如果不同项目需要的是不同版本的包的话就会很麻烦。如果采用统一的系统Python环境（这里先定义一下系统python环境，是指比如windows上安装Python的目录默认是C:python27之类的目录下面的所有python相关内容，而linux因为自带python，就是指系统自带的那套python环境。比如第三方库都存储在/usr/lib/python2.7/site-packages下等等）开发，包也只有一套做不到按项目区分。
解决这个问题的办法就是采用虚拟环境进行开发和维护不同的项目。所谓虚拟环境，其实就是说在系统Python环境之外另搭一套python环境，这套python环境可能借用一部分系统Python环境的内容，而自身补充另一些。身处虚拟环境上下文中的程序将会按照虚拟环境给出的边界来运行。
建立和管理虚拟环境的简单工具就是virtualenv了。virtualenv在linux平台和windows平台上都可用，而且它会根据自己所在的具体平台来改变一些配置适应当前OS。
安装virtualenv十分方便，只要pip install virtualenv即可。这表明virtualenv其实也是用python写成的一个包。但更加方便的地方在于，在pip安装过程中会为我们在系统的可执行文件目录下（linux的话就是/usr/bin下）为我们设立一个virtualenv的可执行文件。也就是说在命令行直接键入virtualenv就可以了。下面将以linux（CentOS7）为基础，说明virtualenv的用法。
■ 基本使用
在命令行键入virtualenv <虚拟环境目录名>就可以在当前位置生成一个虚拟环境的目录，虚拟环境的目录名也就是虚拟环境的名字。打开这个目录我们可以看到主要有bin，include，lib等目录，其中重点关注一下bin和lib两个目录。bin目录下顾名思义放着一些可执行的二进制文件，进去之后可以看到除了python以及几个不同名字的python软链之外， 还有pip和easy_install这俩。就知道了，虚拟环境生成时自带了pip和easy_install这两个重要的工具，方便后续环境的搭建。lib目录可以看到最下面有个site-packages目录的。这个目录当然就是一些第三方库的目录了，默认情况下生成的这个目录中是只带有一些基本的第三方包的。传说加上--system-site-packages作为参数可以把系统python环境中的第三方包完整地拷贝过来，但是试了一下并不行。（刚才试了一下，--no-site-packages和--system-site-packages的主要区别是在虚拟环境架设完毕后进行pip安装时，如果本来系统环境中存在了想要装的包，指定--no-site-packages的会把那个包复制到虚拟环境的lib中，后者则不会。但这也不绝对。。比如我想pip install flask flask-bootstrap的时候，装flask包时确实能体现这个区别，但是装flask-bootstrap的时候，无论用啥参数flask-bootstrap文件就是不被复制过来。。）
另外在目录下还可以看到一个activate文件。这个文件是进入虚拟环境的入口。键入source activate就可以看到命令行的提示符前面多出了一个小括号，括号中是虚拟环境的名字。进入虚拟环境之后，键入pip，python等命令时运行的就不再是系统python环境中的那些命令了。用which python就可以看一下，显示的应该已经不是/usr/bin/python了。因此，在这个环境中（无论你在哪个目录下），只要调用了python命令来运行脚本的话，那么它所用的第三方库等上下文就是虚拟环境的上下文了。所以在虚拟环境的lib目录下安装想要的第三方包，然后用这个虚拟环境的python启动程序，就可以使这个程序或者项目处于一个相对独立封闭的环境中了。
说到安装，虚拟环境中自带了pip，也就是提示我们可以用pip安装。而且pip安装方便的一点在于，如果你要安装的包已经存在于系统python环境中了，那么pip不会再去PyPI上面下载，而是直接从系统环境中复制过来就好，所以安装速度也大大提高。另外，用pip freeze > requirement.txt这个命令可以将虚拟环境上下文中的python包的要求和依赖固化到requirement.txt这个文件中。当程序进行迁移但环境没有迁移的时候，只要在新环境中键入pip install -r requirement.txt来一口气安装所有这些依赖即可。将虚拟环境和pip freeze两个东西结合起来用十分方便
■ 关于程序迁移的问题
项目开发过程中，常常遇到的就是在开发环境开发完成之后上线生产环境，但是生产环境的python环境不一定和开发环境一致，引起很多麻烦。
此时用虚拟环境可以节省力气。比如生产环境上面装了virtualenv，那么就可以在合适的地方建立一个虚拟环境，然后activate进入这个虚拟环境之后根据开发环境中固化下来的requirement.txt在虚拟环境中pip install -r requirement.txt。一口气就可以把所有依赖包都装进去。然后进入虚拟环境，用虚拟环境python启动程序（或者直接通过路径调用虚拟环境目录下的bin/python来启动）就可以做到和开发环境一样了。
不过能这么做还是比较好的情况，假如生产环境没网呢？这时得想另外办法。在有网的地方搭建一套虚拟环境然后pip install相关包然后再把那些文件复制过来不失为一个好办法，不过略显麻烦。另一个办法是这样的：直接把开发环境的整个虚拟环境复制到生产环境上，如果复制过去之后的路径相比于开发环境有变化，那么可以改动一下activate中VIRTUAL_ENV这个即将被添加的环境变量为新目录，这样就可以保证source activate出来的虚拟环境仍然是保持虚拟环境而不是变成了系统环境。（其实看下activate的代码不难发现，所谓虚拟环境只是在source activate的时候增加了一点环境变量，包括把虚拟环境下bin目录添加到PATH中并且先于原先所有PATH，所以在键入python的时候调用的是虚拟环境的python了，其余一些环境变量也类似。deactivate就是把这些环境变量恢复原值。）然后在项目中添加一个启动脚本，这个脚本先进入虚拟环境然后调用python启动程序，一切就和开发环境一样了。
请注意：上面的迁移要成功有一个大前提，就是生产环境和开发环境的python版本要一样。。。如果在python2.7下开发，迁移到2.6上很可能就会报缺少libpython2.7.so.1.0之类的错误。如果真的想要一站式解决这个问题，比如想把这个程序移植到没有python的环境中去，那么需要把整个python都安装过去。
■ windows下的virtualenv
windows下的virtualenv生成的虚拟环境的目录和linux下不太一样。主要区别在于bin目录被改名成Scripts目录且里面都是一些.exe文件包括activate。然后lib改叫Lib了。其他的好像倒也都类似
■ virtualenvwrapper
有空再补充吧。。