Coming from any language with a package manager to C or C++ is like a trip back to the dark ages. Sometimes homogeniety is much much better than flexibility. I too prefer a slimmer std lib with a sane package manager over batteries included (and kitchen sink, and now outdated gfx api). You might get shit like leftPad.js, but you'll also get a very very vibrant ecosystem.
The problem is that the community has already diverted in the way to organize sources, and each of them believes they have the best solution. Similarly, all C++ issues originate from the fragmentation of community: some (maybe 2/3) prefer include a network lib because it facilitates their daily development, while others (maybe 1/3) may have different ideas because they don't use it/they need performance over usability/they want to use this on embedded systems/their own stdlib fork doesn't want to support it. Meanwhile the committee cannot enforce everyone in the community to do something because it has no real-world control on either compiler dev/user community.
The concern over fragmentation is why believe conan's approach is the best: decouple dependency management from build rather than forcing everyon to align on build.
Still has its hurdles but it is a step in the right direction for trying to wrangle the wild west of C++.
You also inherit an entire chain of trust over code you yourself didn't write nor did anyone actually validate. The issue with leftpad.js wasn't that it was stupid, it was that it was dangerous.
That concern is somewhat orthogonal to the utility of a package manager itself. If you are using OSS in any way you need to pick and choose what you take on as a dependency. The package manager solves problems like distribution, dependency resolution, and discovery. The ease of use may contribute to poor decision making, which should not be wholly discounted.
To piggy back, this also goes down the dependency chain. Leftpad wasn't bad because it was being used directly. Projects imported other libraries which either directly pulled leftpad or, more likely, pulled another library which may be the calling party or not.
I disagree. Especially if those non-std libraries are built on other non-std libraries and so on. Trusting a single organization is much easier than trusting a chain of organizations.
There are plenty of ways to organize C++ code, including several package managers. Why should a language -- a specification for a grammar and an abstract machine to run programs using it --- specify things so concrete as the way you download code? It might as well dictate what editor you use.
We need less, not more, conflation between languages, runtime environments, build systems, and package repositories. It's senseless to couple these concepts.
And yet having coded in Rust, Cargo solves all this bikeshedding. You can of course use your own build system but Cargo is pretty consistently used across the board which finally makes developing in a systems language as easy as Python (like virtualenv & pip but better).
Not really, cargo still doesn't provide an answer for binary libraries, and depending on how the workspace is configured and the projects one is compiling, it may end up compiling the same crates multiple times.
I feel ok about making binary libraries difficult. I want open source to be the easy path. I think the idea of abi compatibility forces a lot of unnecessary overhead on designs. Consider the radical design of TempleOS where everything is c source, jit compiled when run.
Which is ok, assuming the Rust community doesn't want to be represented in such markets and doesn't have an issue waiting for cargo building always from source.
>I'm guessing your on an OS without a package manager or not making use of it?
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.
> 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.
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?
>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.
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.
Dependency hell comes from binaries that insist on not using the shared library provided by the distro through the package manager. Windows suffered from not having a package manager in the dark ages, leaving installers to silently clobber each others' changes.
I like the absence of a package manager at the language level and the embracing of shared objects and stable ABIs by using the OS package manager. Missing a library? Just install it, and list it as a dependency in the .spec-file, or whatever packaging system you use.
