4 ms·

Almost every C++ codebase out there vendor all dependencies. Looks like they are not using the system package manager. Windows has no package manager with such

by p0nce 12y ago

Almost every C++ codebase out there vendor all dependencies. Looks like they are not using the system package manager. Windows has no package manager with such library releases. Language package managers have problems, but they do make the work easier. Anyone here unhappy with pip?

frankzinger 12y ago
> Almost every C++ codebase out there vendor all dependencies. Looks like they are not using the system package manager. Yeah, e.g. Chromium. But that was also the reason why Fedora refused to provide packages for Chromium. Distros don't like projects that include their own versions of libraries because it goes against how things are supposed to work (maintenance and, by implication, a security nightmare). I know that there are many C++ projects in the various distro package repos, and no way do 'most of them' include their own copies of dependencies.
- p0nce 12y ago
  In the closed source world I'd say most codebases are like Chromium (difficult to say of course). It's a bit like distributing an application with binary libraries and a no-go for security indeed.
  - frankzinger 12y ago
    Yeah I am sure it's very common in closed source or internal systems. One place I worked at recently did that. All of my comments are about open source systems such as Linux and BSD.
e12e 12y ago
It might not be usable/in use - but doesn't nuget support c++? http://blogs.msdn.com/b/vcblog/archive/2013/04/26/nuget-for-c.aspx http://blogs.msdn.com/b/vcblog/archive/2013/04/26/nuget-for-... > Anyone here unhappy with pip? Pip has (had) a number of issues (mostly related to pypi/availability) -- but pip+virtualenvs is something I use all the time, and am very happy with. The ease with which one can simply: virtualenv some_experiment # --no-site-packages # is now standard! yay! ./some_experiment/bin/pip install -U pip distribute # sadly needed -- but gets us pip list --outated, which # is very helpful ./some_experiment/bin/pip install <thing-to-test> And then just work with that, without even having to mess around with sourcing the "activate" script etc for most packages is great. No clutter under /usr/local, no broken system tools due to some dependency being pulled in etc.

by p0nce 12y ago

frankzinger 12y ago

> Almost every C++ codebase out there vendor all dependencies. Looks like they are not using the system package manager. Yeah, e.g. Chromium. But that was also the reason why Fedora refused to provide packages for Chromium. Distros don't like projects that include their own versions of libraries because it goes against how things are supposed to work (maintenance and, by implication, a security nightmare). I know that there are many C++ projects in the various distro package repos, and no way do 'most of them' include their own copies of dependencies.

p0nce 12y ago
In the closed source world I'd say most codebases are like Chromium (difficult to say of course). It's a bit like distributing an application with binary libraries and a no-go for security indeed.
- frankzinger 12y ago
  Yeah I am sure it's very common in closed source or internal systems. One place I worked at recently did that. All of my comments are about open source systems such as Linux and BSD.

e12e 12y ago

It might not be usable/in use - but doesn't nuget support c++? http://blogs.msdn.com/b/vcblog/archive/2013/04/26/nuget-for-c.aspx http://blogs.msdn.com/b/vcblog/archive/2013/04/26/nuget-for-... > Anyone here unhappy with pip? Pip has (had) a number of issues (mostly related to pypi/availability) -- but pip+virtualenvs is something I use all the time, and am very happy with. The ease with which one can simply: virtualenv some_experiment # --no-site-packages # is now standard! yay! ./some_experiment/bin/pip install -U pip distribute # sadly needed -- but gets us pip list --outated, which # is very helpful ./some_experiment/bin/pip install <thing-to-test> And then just work with that, without even having to mess around with sourcing the "activate" script etc for most packages is great. No clutter under /usr/local, no broken system tools due to some dependency being pulled in etc.