41–50 of 106 posts
Bit of a tangent here but what’s a pip/npm/cargo like package manager for C++? For example ‘pip install boost’? I’ve never worked it out for hobby projects and never worked with it commercially
And many people in the community are against it, you'll hear stuff ranging from "just use the distro package manager" to "don't use any, make it a single file library".
Personally, I'd say all hope is lost.
Bit of a tangent here but what’s a pip/npm/cargo like package manager for C++? For example ‘pip install boost’? I’ve never worked it out for hobby projects and never worked with it commercially
If you control the compiler AND build system you can get away with just one package for most cases. This true for Microsoft’s C/C++ package manager, NuGet[3]
Historically, the convention has been to use the package manager of the underlying system to install packages, as there are so many different build configurations to worry about when packaging the libraries. The other advantage of using the system package manager is that dependencies (shared libraries) that are common can be shared between many applications, saving space.
[2] https://docs.conan.io/1/creating_packages/toolchains.html
Earlier quoted context omitted.
A version number is just a label, and labels are mutable. A lock-file containing hashes will always resolve to the same packages (or fail).
Depending on a single specific version is wrong. A library can be changed to fix a bug without changing the interface in any breaking way. It should be possible for a user (also their package manager, automatically) to replace the library with the new version in this case.
Just because someone says X does Y, it doesn't mean it does.
For anything serious you absolutely verify checksums. Ideally you also mirror every dependency used so you don't care anymore about what's out there.
The thinking in your comment lead to Maven range and npm general atrocities.
Bit of a tangent here but what’s a pip/npm/cargo like package manager for C++? For example ‘pip install boost’? I’ve never worked it out for hobby projects and never worked with it commercially
There isn't any. There are a few partial ones like conan, etc. And many people in the community are against it, you'll hear stuff ranging from "just use the distro package manager" to "don't use any, make it a single file library". Personally, I'd say all hope is lost.
In my experience, most of the value of Conan is with creating packages yourself when needed. You can then self-host a Conan remote and have pre-compiled binaries ready development. Having a conan recipes repository with CI that produces binaries for each required build configuration has become a de-facto standard for projects I have worked on
Bit of a tangent here but what’s a pip/npm/cargo like package manager for C++? For example ‘pip install boost’? I’ve never worked it out for hobby projects and never worked with it commercially
The closest thing we have at the moment is conan[1]. It’s a cross platform package manager that attempts to implement “integrations”, whereby different build systems can consume the packages[2]. This is a big problem with package management in C/C++, there’s no single, standardised build system that most projects use. There isn’t even a standardised compiler! So when hosting your own packages using Conan, often you n…
Earlier quoted context omitted.
A version number is just a label, and labels are mutable. A lock-file containing hashes will always resolve to the same packages (or fail).
Depending on a single specific version is wrong. A library can be changed to fix a bug without changing the interface in any breaking way. It should be possible for a user (also their package manager, automatically) to replace the library with the new version in this case.
Earlier quoted context omitted.
Depending on a single specific version is wrong. A library can be changed to fix a bug without changing the interface in any breaking way. It should be possible for a user (also their package manager, automatically) to replace the library with the new version in this case.
No, it isn't. Just because someone says X does Y, it doesn't mean it does. For anything serious you absolutely verify checksums. Ideally you also mirror every dependency used so you don't care anymore about what's out there. The thinking in your comment lead to Maven range and npm general atrocities.
Every time an old unmaintained Linux app I need fails to start, saying it needs some libsomething.2.3 which isn't in the repos already I just symlink the libsomething.2.5 to it and it works great.
Some times this even helped me to overcome bugs/vulnerabilities.
Being able to fix a bug and update a library without the program even knowing (whithout having to get and rebuild the source or contacting the author) is why dynamic linking has been introduced in the first place, isn't it? Isn't this the "unix way"? Is having a program superglued to an outdated library with known (and fixed already) bugs really what you want?
The author added a lockfile without understanding why they exist. A lockfile is meant to "freeze" dependency version resolution when package authors can specify dependencies on other packages using version ranges... it also "freezes" choices of transitive packages' versions when different packages depend on the same one, but with different versions. They chose to not handle package dependencies at all, and I believe…
I'd expect you'd have human readable file to list your dependencies and versions in a simplistic way, and then a separate machine readable file that locks the versions for reproducibility. As it stands, the example in the article does not look pleasant to write by hand so you'd have to script something yourself.
Why do we need a separate package manager for every programming language and every extensible library/app?
Once we understand package management better -- we don't understand it well yet -- it will likely be feasible to consolidate many package managers into a few omnimanagers.
Earlier quoted context omitted.
No, it isn't. Just because someone says X does Y, it doesn't mean it does. For anything serious you absolutely verify checksums. Ideally you also mirror every dependency used so you don't care anymore about what's out there. The thinking in your comment lead to Maven range and npm general atrocities.
Every time I download someone's code I replace all the == requirements with >=s and it works perfectly (I understand there are many cases when it wouldn't). Every time an old unmaintained Linux app I need fails to start, saying it needs some libsomething.2.3 which isn't in the repos already I just symlink the libsomething.2.5 to it and it works great. Some times this even helped me to overcome bugs/vulnerabilities. B…
It depends on what you want to do.
If you're hobby hacking stuff, sure.
Any kind of software that's supposed to come out of software engineering, probably not.