为什么要用conda而不是pip呢？
搞科学的人都知道打包是多语言的问题。 虽然也可以使用基于系统的非python库进行安装，但是当尝试处理依赖于这些工具的多个版本的多个项目时，经常会出现一些问题。 此时Conda几乎成了唯一的道路。 此外，Anaconda还有为Intel MKL编译的软件包。 这样也可以提高性能。
pip结构更慢
停止使用根环境
当人们开始使用conda/anaconda时，他们倾向于使用根环境(安装程序创建的环境)做所有的事。 然后，在根的环境崩溃，最终束手无策之前，开始在里面设置很多东西。
根环境崩溃时的我
相比之下，为每个项目创造独立的环境更容易。 失败后，可以轻松删除它们，然后重新开始。 根环境是用于安装conda的地方。 说真的，你的根环境应该只用于康达的升级。 其他所有事情都交给其他环境吧。 那样的话，你的编程生活会更长久更幸福。
开始使用Conda构造函数
如果要为组的用户管理anaconda环境，生成器将是一个好工具！ 用于在OSX/Linux/Windows上安装Anaconda和miniconda的安装程序是使用生成器构建的。 通过使用生成器，您可以使用各种规范来构建自己的安装程序，从而无需依赖anconda安装程序，而可以基于团队所需的数据科学环境来构建安装程序。
使用生成器创建的安装程序是部署生产APP的好方法。 安装文件的优点是，所有二进制文件都打包在可执行文件中，因此它们往往相对较大，但在安装时不需要依赖网络。
由于Conda构造函数无法使用noarch包处理——，因此可能会变得不方便。 (noarch软件包是一组独立于平台的软件包——，表示已为linux/osx和windows构建了软件包。)。 实际上，许多库(如django )看起来独立于平台，但实际上依赖于平台特定的包。
不要过分依赖环境修改
通常，建立和销毁环境总比无限期地修改好。 其理由是环境最终会变成奇怪的状态。 我知道这听起来最糟糕的——发生这种情况的主要原因是，随着时间的推移，conda将继续升级，但很可能与旧环境不兼容。 另外，随着时间的推移，你会不断地修正环境，环境通常会持续成长。 因此，康达最终并不理所当然(而且运行得更慢)。
小心使用NFS
系统管理员和devops通常为多用户安装集中的conda环境。 这些环境中支持了一些缓存包。 这些高速缓存包通常存在于世界上一个可读、不可写的地方。 用户创建自己的conda环境后，最终会将自己的软件包下载到自己的主目录中。 这是因为您通常没有写入系统管理缓存包的权限。 Conda可以从多个缓存包中符号链接包。 这当然是件好事。 但是，在主目录中装载NFS后，如果用户尝试在没有相同缓存包的多台计算机上使用自己的环境，则会出现问题。
机器a有一个集中安装在/opt/anaconda下的anaconda。 zero MQ=4.2.5=包括HF 484 d3e _ 1在内。 所以当我用~/.conda建立自己的环境时，那个包就会通过符号连接到我的环境上。 但是，如果尝试在机器b上使用该环境，如果缓存包不包含zeromq=4.2.5=hf484d3e_1，则会导致环境崩溃。
有几个选择
1、确保集中于各机器的环境始终相同
2、禁止用conda进行符号链接
我的建议是都做。 拥有同样的集中环境的想法相当好。 也就是说，无论用户走到哪里，都会得到同样的东西。 此外，在共享环境中，禁用符号链接很有用。 因为如果您升级了中央环境，最终用户环境(通过删除软件包)可能会遭到破坏。
在生产环境中不要太担心conda激活器
Conda激活器设置路径和一些环境变量。 这些环境变量表示Conda安装内容的环境。 部署APP时，这一定会转移你的注意力。 部署APP应用程序时，在启动脚本中引用二进制文件的绝对路径要比调用激活器容易得多。 编辑：通常是正确的，但是我听说有些软件包(pyspark/rpy2 )依赖于这个路径。
部署生产环境时，不要试图解决依赖关系
可以创建依赖于sci工具包- learn的APP应用程序，然后创建APP应用程序的conda清单并将其部署到生产环境中。 这不是你第一次上战场。 你做了明智的选择，然后一切就开始了。 你设定
进入你的名单。 不
常棒！ 但是请注意，scikit-learn还依赖于而且无需指明它依赖于哪个版本。如果你使用scipy 1.1.0进行测试，然后sqdlq要部署scipy 1.2.0时，conda solver将会自动使用最新的版本，这样你的生产环境就是1.2.0版本，这样还省却了程序的兼容性测试。
如果要确保所有嵌套的依赖关系都在生产之前完全解决。有两种方法可以做到这一点。一种是使用conda env export来精确导出每一个想要部署的包的规范(精确到构建号)。这一切的动作必须发生在与生产环境部署相同的平台上。另一种方法是使用构造器。构造器好就好在安装用构造器构建的东西时，不需要再对conda存储库有依赖。唯一的缺点是，由于所有东西都被塞到构造器安装程序中，所以你要部署的文件大小通常至少是几百兆字节，可能是几千兆字节。
如果我需要的包不在Anaconda里呢
首先检查Conda Forge。Conda Forge是一个用来构建所有东西的社区项目。有很大几率你需要的包就在那里，可以通过conda命令
指定conda-forge通道来安装它。
如果失败了——你可以使用conda skeleton从pypi包中生成一份conda清单。同时你还需要构建并上传包到你自己的存储库中，因此这可能会很麻烦。
如果觉得构建自己的包太繁琐，推荐使用pip。我这样做是为了做探索性的工作。无论怎样，我都建议你在发布到生产环境之前先构建适当的conda包。这样做的原因是，对于不能完全依赖于pip的部署中，在进行部署(使用anaconda构造器或conda env导出)之前，确保你的依赖关系已经完全解决。
英文原文：https://www.opensourceanswers.com/blog/best-practices-with-conda.html 译者：能干的盼望は神様