This kind of thing is the reason that header files should die and a new module system should emerge in the world of C/C++. "Header-only" should stop being a novelty. Distributing or consuming libraries should be much more straightforward and easy as with modern languages. I'm not sure C++20 modules are the solution, but this certainly isn't.
A good packaging system for C/C++ would go a long way. CPAN, php pear, pip, go get, etc, etc. all have at least decent package management, support for third part repos, and ways to add a package without using the manager for things you've manually downloaded / coded yourself.
Trying to get multiple C packages from third parties all working together is rough compared to other languages. Rust has me a little spoiled, I guess.
I think it's easier for Rust (and other languages such as D, Crystal), because they started from scratch. Cargo is accepted as the way to build and distribute stuff on Rust, full stop. There are no endless debates whether Cargo should be used, or something else.
Meanwhile, in C/C++ world, build systems are a mess. You have so many tools. Some folks just use what IDE provides, e.g. MSVC solutions. Some people use CMake. Some people have their handcrafted Makefile solutions. Sure, it works on their platforms, but it's very hard to make it portable. With Cargo and similar, you just go "cargo get" (don't know the exact command, don't use Rust) and you can expect the packages to download and build as needed.
What's wrong with apt is that you can't get what YOU want: you can only get whatever the Debian people decided makes sense for one specific version of the OS - which usually means a 2 years out of date version of the library.
If you need a library of a version other than the Debian approved version, you are back to manually downloading source tarballs from sourceforge and figuring out their arcane build system.
Also, apt doesn't let you have two versions of the same library installed. For SOME things, they have more than one version package, but in general, you can't have STABLE_VERSION installed for your day-to-day OS usage and DEVELOPMENT_VERSION installed for your development needs. You only get one or the other (this isn't exclusive of apt - all Linux package managers do this, AFAIK).
Anyway, contrast that situation with pip (python), where you can just grab whatever version you want, have the package manager solve the dependencies for you, and slap it all into a virtualenv where it won't interfere with your system-level libraries. Heck, you can even grab versions straight from git, and it will (try to) solve the dependencies (if any).
First of all, the most popular apt-based distro is not Debian, it is Ubuntu. Second, you can set your apt sources to whatever you want. Plenty of people publish apt repositories other than the Ubuntu project. Confluent for example makes all their software (Kafka etc) available through their own apt repositories.
That random file you downloaded off the internet was built under a specific set of assumptions - assumptions that only hold true if you are running the specific OS version they were targeting.
IF you download the .deb file for your specific OS, and IF you manually install all missing dependencies, then it works. Otherwise, you are still screwed.
At least you can extract it (IIRC, it's just a zip file anyway). But that's no different from going to sourceforge or github or whatever and getting the source tarball... and we are back where we started.
By the way, I was not complaining about "vendor lock-in". I was complaining about Debian's package management policies and how they can affect your software development process in practice - to make the case that apt is a crap replacement for a proper language/library/development/whatever oriented package management.
Yes, it turns out that installation of software has the assumption that you're putting it on the right OS. This is the case for Windows, for Mac, and so forth.
I've never had an issue with a deb package, but I'll tell you it's one of the reasons I stick with Ubuntu for home.
Why would a Linux package manager support Windows which has its own very different package format? I can't ever recall installing a Windows package that decided it would go and download some other dependencies - or at least not transparently. The two are vastly different beasts.
This is C, not JavaScript. Does anyone really want an npm of the C world?
Header files work. They've worked for many decades. Yes, they require software authors to _do more work_, but they also help to eliminate a lib/ directory with 10,000 interdependent libraries that quickly becomes untrusted and frankly, ridiculous.
The npm of the C world is the dozen different package management systems that people have crafted and spent countless hours on. They work, but the lack of a standard makes it a bit cumbersome. Building a .deb is like trying to run a american ninja course, lots and lots of esoteric obstacles. Sure you can hack a .deb, but there's about 2 dozen tools to actually make one that works like the real deal instead of your ad-hoc tarball.
I'm not sure what you are criticizing really. npm is by far better than what we have in the C world, and why npm in particular? Because it's easy to bash?
Far better? Lol nope. In the C world the OS distributions and the general nastiness of shipping libraries outside of an OS distro at least turn away the newbies who think that the world needs yet another module that pads a string to X length.
The hardness of C is its weakness but also its strength. C programmers at least tend to know basic programming and OS management skills while JS programmers... oh hell I'm happy I got out of the mess that is "modern" frontend development.
oh I do have: the easier it is to publish code/packages, the more newbies and morons will flood your environment, to the point of unusability (or at least inability to do any sort of audit).
npm as a package manager is good in theory. But in practice, it does tend to create a culture of "just use a package" for everything. For example foreach [0].
While I do easily agree that npm has created some sort of unwanted culture, I still think this culture was born partly because it's easy to publish/import. I can't say the same of the C world, moreover, there isn't only npm in the package management world.
> This is C, not JavaScript. Does anyone really want an npm of the C world?
I don't care for the deep dependency chains of npm, but integrating C libraries which use a mix of different build systems, and making sure your complete project cross-compiles cleanly with different toolchains for different arches is just irritating and time consuming. I don't think the situation is ideal.
Its existence is my argument. The only reason single-header libraries exist is that library management in C/C++ is terribly cumbersome. We shouldn't need them at all. There is a reason source only distributions are practically absent in almost all modern languages.
