之前在这个帖子讨论&整理了一些，但基本上没什么人用：
希望微软这个 vcpkg 也能像 lsp 一样慢慢流行起来，并覆盖 Linux & macOS。
刚刚看了vcpkg 不是为通用做准备的，只是vs提供的一个功能, 所以不可能会在linux上流行的。
目前是吧，但是也不能完全排除，在 faq 里有写：
Does Vcpkg run on Linux/OSX?
No, for this preview we are focusing on Windows as a host platform. If you’d be interested in having Vcpkg run on Linux or OSX, please let us know in this issue!
所以，最后成不成，要看点赞人数了。
UPDATE
那个 issue 的末尾有这么一个链接 https://blogs.msdn.microsoft.com/vcblog/2018/04/24/announcing-a-single-c-library-manager-for-linux-macos-and-windows-vcpkg/
1 个赞
C++包管理器出了一个又一个，到最后也没有能一统江山的，希望这次MS能成功。
C++包管理器凭什么成功？*nix下任何一个软件包管理器不是单纯的C++包管理器的超集？
pip为什么成功？那还不是python足够跨平台，然后python程序员只往pip源里发布就行了。C++是这么回事么？
1 个赞
我觉得微软推出c++ 包管理器的根本原因是 Windows 就没有包管理器，像Unix 系的操作系统，那个没有个像样的包管理器呢？下载依赖和下载应用包一样: apt-get install libsdl2-dev, 我既能下载应用又能下载依赖，为什么要舍弃现有的工具链去用你的只能管理c++ 包的包管理器呢？
1 个赞
其实一个系统里多个包管理器挺不爽的，一个主要的包管理器外加几个特定语言的管理器。如果有一个统一的标准发布包，所有的管理器用一个源就好了。
系统软件包管理器在全局范围内一次只能安装／激活一个版本的 lib，而每个项目各自都有不同的依赖。把系统包管理当作开发依赖管理使用，公（全局）/私（本地）不分，会带来很多问题。
之所以长久以来没有 c/c++ 包管理器，是因为历史问题。荒蛮年代也无所谓包管理，一锅扔到 /usr/lib 煮就是了，后来起了冲突，就发明各种复杂的构建系统来应对，在错误的道路上越走越远。
而另外一些语言由于跟系统关系没那么紧密，迫使它们发展出了自己的包管理系统，这才是正确的道路。go / rust 这些新一代语言，更是出生就自带包管理属性。
c/c++ 包管理器会不会成功，跟它好不好没有必然联系。就像你觉得公司现有的代码一坨翔，但是也只能任由它继续存在，不会轻易去改动。
程序员生存手册#67: 旧代码能用就别瞎改
go / rust 这些新一代语言，更是出生就自带包管理属性。
Rust 的包管理器cargo 是我用过最好用的，只不过 go 的包管理能力基本处于残疾级别。C/C++的依赖管理真的要跪了， python 的包管理也没有好到哪里去，割裂的py2和py3 导致 pip, virtualenv, pipenv这些依赖管理工具，模块管理工具要混在一起用
python……只要不同时用py2 py3，一切都好说。
py2/py3 的锅不应该让包管理器来背。不过 pip 确实存在问题，把 package 安装到全局位置，跟 apt-get 有什么差别？
我也觉得不爽，我之前python的包是通过系统的包管理器装的，然后，有个python写的makefile转compile_commands.json的工具，系统源里没有，我就没装了。 至于emacs的话，幸好一开始就用的emacs的包管理器。。。
gtk2和gtk3就是不同的包，不复杂啊。。。
所以pip 把package 安装到全局位置，所以就无法将全局的package 和项目的package 隔离开，为了解决这个问题，就出现了 virtualenv 来虚拟化一个项目，然后再在项目里安装依赖，后来感觉不是非常好用，又来了个virtualenvwrapper, 然后为了一次性解决安装依赖和管理依赖的问题，又来了个pipenv
conan怎么样呢？
我认为针对项目的包管理主要有两个优点：
-
把依赖／约束明确写在文件里。这份文件不仅仅是给人看的（哪些包，做什么用，心里有数），也是给工具看的（如何构建 & 使用包）。有了这份文件，在一个全新的环境中也能很快进入工作状态。
-
隔离／非侵入。增／删／改／升级不影响其他项目，反过来也是一样。虽然隔离不一定要使用包管理器，但这是一个比较实惠选项。
我感觉 python 的 virtualenv 挺好的，可以在虚拟环境里包含系统安装的 python 包，用 pyenv 以及 virtualenvwrapper 管理，python 2 和 python 3 混着用，没有感觉有什么不好。不过可能我的使用范围只限于科学计算，不具有一般性。emacs 当中随时切换虚拟环境，比如我的 py2 没有 bz2 文件读取支持，我就 ,vw 切换到 python 3 中读取，配合 lpy 交互执行，很 happy。
借道问一个问题，因为某种原因必须要用系统自带的 python，有办法令系统自带 python 支持 bz2 格式吗？每次都切换虚拟环境还是麻烦了点。
哎哟，不觉得用个包管理器玩c 系语言很怪么，可移植性呢，包管理器可以给你搞定。。？