3 ms·

What was the logic behind rubygems adding support for Gemfiles? I can see why Gemfile.lock support is a good thing, but adding a new, incompatible runtime depe

What was the logic behind rubygems adding support for Gemfiles? I can see why Gemfile.lock support is a good thing, but adding a new, incompatible runtime dependency resolution mechanism to that provided by Bundler seems like an odd choice.

jrochkind1 13y ago
Gemfiles _are_ bundler's dependency resolution mechanism; it's not a new incompatible mechanism added to that provided by bundler -- it's bundler's mechanism being merged into rubygems itself. Which is great news, in my opinion. With the same team, release schedule, and set of tests, there will no longer be issues of which version of bundler works with which version of rubygems (which isn't an issue except when it has been, and then it sucks, especially for newbies). No extra thing to install (including in your provisioning/deployment scripts). It's just there, it just works. The number of seperate interacting parts you had to install to 'bootstrap' a proper ruby installation has been growing -- which really does add increased burden to newbies understanding what's going on -- nice to shrink it again.
- regularfry 13y ago
  > Gemfiles _are_ bundler's dependency resolution mechanism No, Gemfiles are the dependency specification protocol. The resolution mechanism is the algorithm which turns that into a set of gems to install or, if you're feeling particularly crazy, require. Right now I can have a Gemfile which bundler accepts, and rubygems barfs on. That's the incompatibility.
  - jrochkind1 13y ago
    I see what you mean, yeah. If I understand it right, this is a temporary state of affairs, as the rubygems/bundler integration is only partway done. The end goal is rubygems handling of Gemfiles and Gemfile.lock will become equivalent with bundlers, and then bundler will disappear. I am curious why they decided to even release the partial implementation on the way. Either way, I'm grateful enough that a rubygems/bundler merge is happening, and we'll never need to deal with incompatibilities between certain versions of rubygems and bundler again once it does, that I'm willing to not be too picky about how they get there.

jrochkind1 13y ago

Gemfiles _are_ bundler's dependency resolution mechanism; it's not a new incompatible mechanism added to that provided by bundler -- it's bundler's mechanism being merged into rubygems itself. Which is great news, in my opinion. With the same team, release schedule, and set of tests, there will no longer be issues of which version of bundler works with which version of rubygems (which isn't an issue except when it has been, and then it sucks, especially for newbies). No extra thing to install (including in your provisioning/deployment scripts). It's just there, it just works. The number of seperate interacting parts you had to install to 'bootstrap' a proper ruby installation has been growing -- which really does add increased burden to newbies understanding what's going on -- nice to shrink it again.

regularfry 13y ago
> Gemfiles _are_ bundler's dependency resolution mechanism No, Gemfiles are the dependency specification protocol. The resolution mechanism is the algorithm which turns that into a set of gems to install or, if you're feeling particularly crazy, require. Right now I can have a Gemfile which bundler accepts, and rubygems barfs on. That's the incompatibility.
- jrochkind1 13y ago
  I see what you mean, yeah. If I understand it right, this is a temporary state of affairs, as the rubygems/bundler integration is only partway done. The end goal is rubygems handling of Gemfiles and Gemfile.lock will become equivalent with bundlers, and then bundler will disappear. I am curious why they decided to even release the partial implementation on the way. Either way, I'm grateful enough that a rubygems/bundler merge is happening, and we'll never need to deal with incompatibilities between certain versions of rubygems and bundler again once it does, that I'm willing to not be too picky about how they get there.