4 ms·

It's far from a solved problem. Many ecosystems haven't gotten past the "single dependency file and lock file" system where an entire project has to use a sing

It's far from a solved problem. Many ecosystems haven't gotten past the "single dependency file and lock file" system where an entire project has to use a single version of each dependency. There are people splitting their project into a thousand "microservices" and making them interoperate over HTTP instead of regular function calls so that each part of their project can have its own dependencies.

rickycook 9y ago
also so that a crash doesn’t stop everything like a BSOD, also so that you can use the language most appropriate for the task at hand because assuming a single language is good for everything is just wrong, also to be able to incrementally migrate things to new PAAS/build systems/etc in the future so you don’t do big bang... and plenty more multiple library versions is one of the lowest priorities when doing micro services id say this is not to say that people don’t significantly over use micro services, but there are plenty of hard problems they solve
JepZ 9y ago
Yes, its kinda funny, I mean package managers are probably the ones with the most solid experience in dependency management and when I look at them I can see many different concepts at work there. Some like for example pacman are bold and are not afraid to break a system during upgrade (as it is very unlikely that the upgrade will fail) and others put an abnormal amount of effort to ensure an always functional system at any time (especially on source based distributions, e.g. paludis). And while I have been using development snapshots for years with my system and didn't have more bugs to cope with compared to other systems, I can understand that developers in corporate contexts need to be able to specify dependencies with versions. So I appreciate that proposal very much and hope it will lead to a better solution for every body involved by providing a way to use versioned dependencies without introducing too much overhead for those who don't need versioned dependencies.
- flukus 9y ago
  Pacman, apt-get, et al also have something most language specific package managers don't, maintainers. Maintainers back port security fixes and are careful not to break binary compatibility. A random $lang specific package is unlikely to have either, if you expect a bug fix you have to upgrade to the latest version. Developers that don't want to provide this sort of stability typically hate distro package managers. No package manager can fix a cultural problem.
  - vk23 9y ago
    If you rely on dependencies that are not maintained you are already in trouble. Being the author/maintainer of a package comes with a responsibility. NPM already showed us what happens if you just let people do their thing.
XorNot 9y ago
With package managers I worry more about how I distribute my dependencies then anything else. Golang's vendor/ directory concept support was a revelation for me - just ship you dependencies alongside your code. Meanwhile, I've heard people spend ages complaining that this is totally wrong...while overseeing setting up local artifactory instances and wrangling proxying to do the exact same damn thing.
coldtea 9y ago
>Many ecosystems haven't gotten past the "single dependency file and lock file" system where an entire project has to use a single version of each dependency. Perhaps they shouldn't go past that.

rickycook 9y ago

also so that a crash doesn’t stop everything like a BSOD, also so that you can use the language most appropriate for the task at hand because assuming a single language is good for everything is just wrong, also to be able to incrementally migrate things to new PAAS/build systems/etc in the future so you don’t do big bang... and plenty more multiple library versions is one of the lowest priorities when doing micro services id say this is not to say that people don’t significantly over use micro services, but there are plenty of hard problems they solve

JepZ 9y ago

Yes, its kinda funny, I mean package managers are probably the ones with the most solid experience in dependency management and when I look at them I can see many different concepts at work there. Some like for example pacman are bold and are not afraid to break a system during upgrade (as it is very unlikely that the upgrade will fail) and others put an abnormal amount of effort to ensure an always functional system at any time (especially on source based distributions, e.g. paludis). And while I have been using development snapshots for years with my system and didn't have more bugs to cope with compared to other systems, I can understand that developers in corporate contexts need to be able to specify dependencies with versions. So I appreciate that proposal very much and hope it will lead to a better solution for every body involved by providing a way to use versioned dependencies without introducing too much overhead for those who don't need versioned dependencies.

flukus 9y ago
Pacman, apt-get, et al also have something most language specific package managers don't, maintainers. Maintainers back port security fixes and are careful not to break binary compatibility. A random $lang specific package is unlikely to have either, if you expect a bug fix you have to upgrade to the latest version. Developers that don't want to provide this sort of stability typically hate distro package managers. No package manager can fix a cultural problem.
- vk23 9y ago
  If you rely on dependencies that are not maintained you are already in trouble. Being the author/maintainer of a package comes with a responsibility. NPM already showed us what happens if you just let people do their thing.

XorNot 9y ago

With package managers I worry more about how I distribute my dependencies then anything else. Golang's vendor/ directory concept support was a revelation for me - just ship you dependencies alongside your code. Meanwhile, I've heard people spend ages complaining that this is totally wrong...while overseeing setting up local artifactory instances and wrangling proxying to do the exact same damn thing.

coldtea 9y ago

>Many ecosystems haven't gotten past the "single dependency file and lock file" system where an entire project has to use a single version of each dependency. Perhaps they shouldn't go past that.