我先前一直是用它的, 那物件自身不存在什么较大层面的问题, 只是每一回设立环境时都得进行一连串的命令敲击操作, 在项目数量增多了之后, 目录当中零散分布着几个.env或者venv文件夹, 看起来令人心生厌烦之感, 并且无法找寻到哪一个环境是与哪一个项目相对应的。有个名为某工具的东西, 它将pip以及另外的功能进行了合并, 你无需再先去创建虚拟环境接着激活, 仅一个某工具就能搞定环境与依赖, 它会生成一个名为某的文件以及.lock文件, 以此来记录项目中的依赖, 如此这般你便不用手动去维护.txt文件了。要么换一台电脑, 不然就让同事克隆项目, 如此一来, 直接便能够还原出完全一模一样的环境这个特性拯救过我两个不同的次。其中一回是在公司的电脑上面进行开发, 一切进展良好,然而等人回到家中时却发觉环境已然崩溃了。之后我采用重建之举, 仅仅是喝了一口水所花费的那段时间就已然恢复如初了。存在一个称作的更轻量方案, 它相较更具规范性, 其依赖解析更为迅速, 运用.toml来管理项目元数据以及依赖, 该文件属于社区当下所推行的新标准, 你无需再去撰写setup.py和setup.cfg那些过时老旧的文件了。有一项贴心功能, 当你进行add操作时, 它便能自动安装依赖并写入.toml, 倘若依赖之间存在版本冲突, 它可会告知你哪一个包与哪一个包不相兼容, 以往你自行运用pip去安装包之际常常会遭遇“将系统弄混”的状况, 故而使用频率就变少了。协作之时, 团队所具备的和之益处要更为显著, 将文件锁定, 如此可确保众人所拉取下来的依赖版本是完全相同的, 如此一来, 你便无需忧心那“于我这边本地环境是能够良好运行的, 然而到了测试环境之际却会出现报错状况”这般的问题了, 先前我的那位同事正是由于这个缘故而额外增多了两小时的工作班时, 倘若能够早点用到这些工具的话, 那么他早就已然下班了。要是你仅只是在偶尔的时候去写一个小脚本, 并且不想对这些工具进行折腾。那么conda可能会更加适合你。conda不仅仅负责管理包, 顺便还管理非的依赖。比如说你安装numpy, 它能够同时将底层的BLAS库也一并处理妥当。这一情况别的做不到。到底选用什么样的工具, 其实这取决于你正在面对的场景。要是处于团队项目期间, 那么建议选用或者之上的那种。而针对个人项目的时候, 或者对于刚入门的情况而言, 选用这种也就足够了。但说实在话, 既然现成存在着更好用的工具, 那又何苦非要跟自己为难呢。