4 ms·

> The speed of the solver is not a problem in any other package management system I've seen This! I've never heard anyone complain about this aspect of a packa

by pcx 8y ago

> The speed of the solver is not a problem in any other package management system I've seen This! I've never heard anyone complain about this aspect of a package manager, EVER. vgo seems to be optimizing for a problem no one has.

baq 8y ago
i've seen aptitude get really confused about what to install and computing a solution for a few minutes. once. 10 years ago or so, i don't even remember.
- pcwalton 8y ago
  I should clarify that I'm referring to language package managers. Their problem domains are significantly different than those of system package managers.
  - asymmetric 8y ago
    I'm curious, what makes the problem domains different? I'm asking because I'm interested in "universal" package managers like nix.
marcus_holmes 8y ago
Go has always optimised for build speed. I guess they considered dependency resolution as part of the build process. Which it technically is, I suppose, but when you're coding and iterating the code-build-run loop you generally don't need to add new dependencies each time. And that's when the build speed matters, of course.
- pcx 8y ago
  And, most CIs cache build dependencies these days which is an easy work around.
jcelerier 8y ago
> The speed of the solver is not a problem in any other package management system I've seen really ? It has been a large problem in Debian for instance and has enabled a lot of research (https://scholar.google.fr/scholar?q=debian+solver https://scholar.google.fr/scholar?q=debian+solver). One of the reason for Fedora's yum -> dnf change was also a change of solver. It's a hard problem that affects a lot of people.
- pcx 8y ago
  To clarify, I(and the OP) was specifically talking about programming language specific package managers.
  - lathiat 8y ago
    puppet dependency managers have also been an issue it's certainly easy to solve poorly
- sametmax 8y ago
  You can't compare languages and os package manager. They are on a completely different scale.
trumpeta 8y ago
Scala / SBT has a particularly slow dependency resolution
amluto 8y ago
I once waited for a long time for an older Haskell dependency solver to contemplate a situation before it gave up.

by pcx 8y ago

baq 8y ago

i've seen aptitude get really confused about what to install and computing a solution for a few minutes. once. 10 years ago or so, i don't even remember.

pcwalton 8y ago
I should clarify that I'm referring to language package managers. Their problem domains are significantly different than those of system package managers.
- asymmetric 8y ago
  I'm curious, what makes the problem domains different? I'm asking because I'm interested in "universal" package managers like nix.

marcus_holmes 8y ago

Go has always optimised for build speed. I guess they considered dependency resolution as part of the build process. Which it technically is, I suppose, but when you're coding and iterating the code-build-run loop you generally don't need to add new dependencies each time. And that's when the build speed matters, of course.

pcx 8y ago
And, most CIs cache build dependencies these days which is an easy work around.

jcelerier 8y ago

> The speed of the solver is not a problem in any other package management system I've seen really ? It has been a large problem in Debian for instance and has enabled a lot of research (https://scholar.google.fr/scholar?q=debian+solver https://scholar.google.fr/scholar?q=debian+solver). One of the reason for Fedora's yum -> dnf change was also a change of solver. It's a hard problem that affects a lot of people.

pcx 8y ago
To clarify, I(and the OP) was specifically talking about programming language specific package managers.
- lathiat 8y ago
  puppet dependency managers have also been an issue it's certainly easy to solve poorly
sametmax 8y ago
You can't compare languages and os package manager. They are on a completely different scale.

trumpeta 8y ago

Scala / SBT has a particularly slow dependency resolution

amluto 8y ago

I once waited for a long time for an older Haskell dependency solver to contemplate a situation before it gave up.