3 ms·

This is one case that rubygems handles well, but I think your specific example is broken. If libcat requires 1.0.0 <= bar < 2.0.0, foo requires libcat, foo requ

This is one case that rubygems handles well, but I think your specific example is broken. If libcat requires 1.0.0 <= bar < 2.0.0, foo requires libcat, foo requires 2.0.0 < bar, you've got conflicting requirements - foo requires both bar < 2.0.0 and 2.0.0 < bar. Rubygems will barf at that. > You have to rename the entire library directory. In my opinion this is an ugly hack around the fact that your package manager doesn't support multiple versions. I think this is solved much more elegantly if the package manager allows you to switch the version on-the-fly... in other words, what RubyGems does. It may be an ugly hack, but it's fairly traditional at this point.

FooBarWidget 16y ago
> Rubygems will barf at that. Only if you activate gems linearly. Bundler solves exactly this: it looks at all dependencies then figures out a combination that works. Bundler will only activate bar 1.x because it sees that foo is compatible with all versions but libcat is only compatible with 1.x. > It may be an ugly hack, but it's fairly traditional at this point. I argue against the notion that being traditional here equals being good. There's no good reason why the developer should do this manually instead of having some system do it for him. RubyGems actually implicitly does this. By installing each gem to its own directory it separates the versions on the filesystem level.
- regularfry 16y ago
  > Only if you activate gems linearly. Bundler solves exactly this: it looks at all dependencies then figures out a combination that works. Bundler will only activate bar 1.x because it sees that foo is compatible with all versions but libcat is only compatible with 1.x. You're absolutely right, I misread your example. > I argue against the notion that being traditional here equals being good. There's no good reason why the developer should do this manually instead of having some system do it for him. It's a trade-off. Either the developer has to do it manually (once, which will then work with every sane distro), or the sysadmin has extra work to do (many times, once for each language-specific package manager). In an ideal world, the language communities would gang up on Debian and Red Hat and improve dpkg and rpm to make this issue go away. I don't see this happening.

FooBarWidget 16y ago

> Rubygems will barf at that. Only if you activate gems linearly. Bundler solves exactly this: it looks at all dependencies then figures out a combination that works. Bundler will only activate bar 1.x because it sees that foo is compatible with all versions but libcat is only compatible with 1.x. > It may be an ugly hack, but it's fairly traditional at this point. I argue against the notion that being traditional here equals being good. There's no good reason why the developer should do this manually instead of having some system do it for him. RubyGems actually implicitly does this. By installing each gem to its own directory it separates the versions on the filesystem level.

regularfry 16y ago
> Only if you activate gems linearly. Bundler solves exactly this: it looks at all dependencies then figures out a combination that works. Bundler will only activate bar 1.x because it sees that foo is compatible with all versions but libcat is only compatible with 1.x. You're absolutely right, I misread your example. > I argue against the notion that being traditional here equals being good. There's no good reason why the developer should do this manually instead of having some system do it for him. It's a trade-off. Either the developer has to do it manually (once, which will then work with every sane distro), or the sysadmin has extra work to do (many times, once for each language-specific package manager). In an ideal world, the language communities would gang up on Debian and Red Hat and improve dpkg and rpm to make this issue go away. I don't see this happening.