4 ms·
Once you've started using language package managers, it become very apparent that they have huge value, that apt-get doesn't bring. In particular, you get the
by pbiggar 9y ago
Once you've started using language package managers, it become very apparent that they have huge value, that apt-get doesn't bring.
In particular, you get the exact version of the library you want. If you've ever had the experience of trying to make your software work with multiple versions of its dependencies because different OSes ship with different versions, then you'll know how annoying this is.
This is particularly true of run-time problems. If they don't compile, then that's relatively easy to fix. If there's a difference at run-time, its often way more expensive to fix.
With a package manager, you get the exact version, but you also can use different versions for different apps on your system. You can also upgrade without breaking other apps (new security version) or not upgrade if there's some good reason not to.
- flukus 9y ago> In particular, you get the exact version of the library you want. If you've ever had the experience of trying to make your software work with multiple versions of its dependencies because different OSes ship with different versions, then you'll know how annoying this is. Isn't this just kicking the can down the road though? The incompatibilities are still something you either have to deal with or users end up with 58 outdated versions of each library and the security vulnerabilities they bring. > Once you've started using language package managers, it become very apparent that they have huge value, that apt-get doesn't bring. This is what's wrong with so much modern development, we do what's easy for developers, not what's best for users.
- pbiggar 9y ago> This is what's wrong with so much modern development, we do what's easy for developers, not what's best for users. In the client software case, software that works is what's best for users. If you upgrade a library and apps start working, that sucks. If you're running server-side software, you want dev-production parity, or you can't know it works. So you _need_ to use a package manager. But the same applies to client software: you can't test all these permutations, so you can't even tell it works, and it probably doesn't.
- flukus 9y agoYou don't think software that's secure is important for both cases? Open up a random project with a language dependent package repository and tell me how many of the packages are up to date? More often than not the answer is zero with commercial software. If you're running server side you should have test environments that match prod to be able to catch incompatibilities early.
- ryandrake 9y agoI'm not arguing against using a package manager. I'm arguing against using 5 of them that don't know about each other.
- nurettin 9y agoI am interested in such a thing (e.g. ruby bundler knowing how to install native dependencies from any package manager), but that means pkg-config or similar ubiquitous tool would have to be able to query all kinds of servers in order to see the versions of packages available.
- Sanddancer 9y agoFreeBSD has had a package called bsdpan for some time that will register items installed through CPAN with the package manager. You may want to poke at that for inspiration on how to do it for other languages. Offhand, for handling multiple systems, it may be most useful to check something like uname and parse accordingly to figure out what's what.