Still has its hurdles but it is a step in the right direction for trying to wrangle the wild west of C++.
The difference is, having an external library allows it to be versioned with breaking changes if necessary, without breaking consumers.
We need less, not more, conflation between languages, runtime environments, build systems, and package repositories. It's senseless to couple these concepts.
Just don't complain about adoption then.
I just went back to C and have spent too many hours trying to get small libraries to build and link properly. I'm pulling my hair out.
Having the OS handle it is a much better solution than having every single language come up with it's own solution.
No one has time to publish their library into the myriad of OS specific package managers that are out there.
That's really irrelevant, and not the proper way to install programming dependencies for developers. It's for installing system dependencies (including libs) and to build software for the system (e.g. as a system admin/user you want to build X and it needs the -devel package installed), not for developers on their projects.
Nobody (or very few) in Rust, Python, Ruby, Go, Java etc would ever use the "system package manager" for installing their language's third party libs.
For one, you don't want to pollute the system with your program's deps.
Second, you want to have isolated, different versions, of various dependencies, only visible to this or that project you work on, not to the whole system.
Completely disagree, the system dependencies are my dependencies and whenever possible I want to be able to "make install" and have my dependencies update with the rest of my system.
> Nobody (or very few) in Rust, Python, Ruby, Go, Java etc would ever use the "system package manager" for installing their language's third party libs.
Java has always been a "fat VM", it's a platform and not part of the system, so not surprising that it handles it's own. For python/perl/ruby, it used to be quite common to include packages from the OS repository, until they reinvented the wheel. For rust, that's why it's a joke as a "systems language".
> For one, you don't want to pollute the system with your program's deps. Second, you want to have isolated, different versions, of various dependencies, only visible to this or that project you work on, not to the whole system.
Entirely doable with existing package managers, just use the -root switch with dpkg or the --prefix switch with rpm or (or configure if you build from source). Typically I only want a small subset of version specific packages.
So why would I want yet another package manager when my existing one is sufficient?
You can disagree, but you'd be wrong in anything that a one-map-shop setting working on a single project, and willing to depend on the distro's (or third party distro package manager repos) versions of language libraries and frameworks.
>Entirely doable with existing package managers, just use the -root switch with dpkg or the --prefix switch with rpm or (or configure if you build from source). Typically I only want a small subset of version specific packages.
Typically this is a luxury that software shops with different projects (including older, already installed), different customers, etc., can't have.
>or python/perl/ruby, it used to be quite common to include packages from the OS repository, until they reinvented the wheel
Or until those languages weren't used merely by sys-admins and one-off scripts, but for large project development, and "include packages from the OS repository" wouldn't cut it anymore.
>For rust, that's why it's a joke as a "systems language".
Total non-seguitur. In fact, one of the main goals of C++ (as per the posted roadmap) is to add a package manager.
But the total non-seguitur that "Rust is a joke as a systems language" because it has cargo I think disqualifies anything else that can be said here.
We don’t need yet another package manager. Every language seems to have to have its own package manager, separate from my operating system’s package manager, that does exactly the same thing but in an incompatible way.
Now, if I want to know what software I have on my system, I need to use five different list commands instead of just one. If C++ had its own package manager, that would mean six. Please help to stop this madness, not perpetuate it.
In particular, distros generally work best when one version is enough, or maybe a few versions. Anything else leads to dependency hell.