Virtualenv or Anaconda？Python虚拟环境最佳实践

最近同时在Window和Linux上交替使用Virtualenv和Anaconda，期间一直在思考两种工具哪一个更好？是否可以统一使用其中一个完成所有Python项目的环境构建？针对这个问题，本文做了一些经验总结，给出一些建议作为参考。提醒注意的是：本文讨论的范畴仅限“基于Windows的个人开发环境”。我们先把结论性的东西放在前面，后面给出一些观察和思考。

最佳实践

1. 两者共存，机器学习项目优先选择Conda，其他类型项目视情况而定，可能多数会以Virtualenv为主
2. 使用更轻量的Miniconda替代Anaconda
3. 依然在本地安装并建立系统级Python环境 （与Virtualenv配合工作）
4. 禁止Conda全权接管本地Python环境和虚拟环境（不勾选：“Add … PATH Variable” 和 “Register Conda as my default python”），避免冲突
5. 通过添加右键菜单更方便地激活并进入Conda环境

观察思考

在机器学习领域，业界公认Anaconda要比Virtualenv好，特别是在Windows（和MacOS）系统上，Anaconda解决了很多底层依赖问题，使得通过Anaconda为在Windows上构建虚拟环境会顺畅很多（比用Virtualenv遇到的问题要少）。就个人而言，我早期的想法是：最好只使用Virtualenv一种工具构建所有的Python项目环境，保持一致的虚拟环境使用习惯和体验。因此，我曾使用Virtualenv构建过一些机器学习项目，结论是：由于机器学习领域的很多Python包（例如gym）需要使用或依赖到更底层的操作系统级别的软件或程序包，通过pip install是不可能自动安装这些非Python的底层依赖的，所以构建过程就会因这样或那样的错误屡屡被打断，需要根据错误信息逐一找到本地系统上缺失的软件，然后手动安装它们才可以修复，相比较而言，使用Anaconda遇到的此类问题要少很多。尽管如此，我还是坚持使用了一段时间的Virtualenv去构建机器学习项目，我最初的想法是：如果使用Virtualenv在构建机器学习项目上遇到的问题不是很多，为了“保持一致的虚拟环境使用习惯和体验”，付出一点代价是值得的。此外，还有一个考量因素是：几乎所有项目都会提供requirement.txt配置文件，却不一定会提供conda使用的yaml配置文件（虽然转换一下也不困难）。以下是我曾经使用Virtualenv构建学习项目时遇到过的一些问题及其解决方法：

错误信息	解决方法	Conda是否存在同样问题
ERROR: Failed building wheel for box2d-py	方法链接	否
Error: Microsoft Visual C++ 14.0 or greater is required	方法链接	否
ERROR: Could not build wheels for AutoROM…	方法链接	是

解决这些问题确实花费了一些时间，整体看下来，在Windows系统上，相比于Conda，Virtualenv确实会遇到更多麻烦。不过截止目前，就我个人在Windows上使用Virtualenv构建机器学习项目所遇到的麻烦来看，还在可接受的范围内。

但与此同时，我也在告诫自己：工具（Virtualenv、Anaconda）可以都学，都掌握，但是别给自己挖坑，既然Anaconda就是为解决这些麻烦而开发的，我们为什么还要去给自己“找麻烦”呢？且这些填坑的经验并没有什么价值，用省出时间学习更多有价值的知识才是更明智的。此外，我还注意到：《Hands-On ML》第三版的工程文档是以Conda为构建工具介绍如何构建项目的，可以看出作者也更倾向于Conda。

所以，总得来说，我可能还会在机器学习项目上并行使用Virtualenv和Anaconda一段时间，直到我在机器学习项目上得到最终的结论：Virtualenv“还行”或是它“太难搞”，然后我将（在机器学习项目上）彻底转向Virtualenv或Anaconda。