这个又跟发行版的理念有关了。
比如debian这种的，理念就是你需要经过一定的测试和成熟度才能进它的体系。那自然会存在许多还没进发行版体系的，只能靠pip安装的东西。

但你既然选择了debian，目的就是享受他的这套理念下带给你的成熟度和方便性。否则你也可以选gentoo呀，一切都从源代码编译，要怎么配就怎么配，没问题的。

当然也有arch这样的，也给你从最新源代码安装的选项。不过这么说其实你也可以自己维护个小的debian repo自己给自己打补丁呀。

所以说，这个事情本质上就是你借用了别人的体系，但当别人的体系满足不了你的需求的时候，你又不想出力在别人的体系内解决好问题，只想简单快速一个dirty workaround跑起来再说，那久而久之自然就是抱怨这个不行那个不好一切为啥这么的乱。这种抱怨在我看来就挺无聊的。

反正现在的趋势是人越来越懒，也越来越弱。所以现在的趋势都是我一个docker什么都包了，down下来一定能跑。我管你是什么发行版，什么语言什么版本。我这个docker里连数据库都带好了开箱即用压根不需要配置。尽管我跑了10个docker，可能每个都配了套apache/nginx，可能10个docker总共有10套mysql/postgresql的数据库要维护。但我不care，让大撕裂来的更猛烈一点吧。（pip的venv同理，只是程度没这么严重而已）

最后说说我的做法。我一般用debian testing/unstable，尽量日常更新。我不用docker，不用venv，不用anaconda之类的repo外管理体系。只用debian repo下有package的最新版本。然后我的各种应用都向当前的debian testing/unstable快照看齐，优先选择进repo的package，没进repo但确实重要无法代替的少部分，我才用pip等脱离repo的手段安装。然后如果某个应用非要tmd绑定在某个落后版本的，我要么就不用它，要么就给它升级到最新版本。这么多年下来，我觉得清爽的很，哪有这么多麻烦。

简单地说，你选定一个主要的package manager为基础（比如我选的是debian repo），那你一切都围绕它进行。它做不到的地方再用第二套管理体系为补充。其他package manager稍用一点是良药，用多了就是毒药，一定要控制使用量，否则就是这篇文章所说的乱成一锅粥的场景
【 在 cat 的大作中提到: 】
: disco只打包Python和主流知名第三方模块。
: 如果需要新版本的Python和新版本/新安装的第三方模块，就需要PIP这样的。
: 如果需要隔离开，就需要virtualenv这样的。
: ...................
--
修改:lvsoft FROM 180.158.54.*
FROM 180.158.54.*