4 ms·
> 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
by 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.