The .gems solution was non-deterministic in the normal use case. If someone specified "sinatra" in their .gems file, they would often end up with a completely different version in production than they were using in development. Sure you could specify an exact version of every gem in your .gems file, but few people did and it's a huge pain to maintain.
Bundler splits dependency declaration into what the developer cares about (Gemfile) and an exact specification of each version that should be installed (Gemfile.lock). This maintains dev/prod parity without the maintenance overhead of curating a specific list of gem versions yourself. It also has the advantage of not being specific to Heroku. Cheers, David On Fri, Apr 6, 2012 at 3:06 PM, Michel Martens <[email protected]> wrote: > Hey Keenan, thanks for replying :-) > > On Fri, Apr 6, 2012 at 2:48 PM, Keenan Brock <[email protected]> wrote: > > Hello Michel, > > > > I think this is a great example of heroku being ahead of their time. > > > > When .gems was introduced, there wasn't a way to specify gem > dependencies in > > a ruby project. > > Back then, dependencies were a mess - heroku even had to run their own > > custom fork of rails. > > There were other means to define dependencies (for instance, Bundler > was initially inspired by this library: > https://github.com/djanowski/dependencies). I think Heroku's solution > was very elegant, and continues to be. > > > > > Now, the Gemfile is a common and standard way of specifying dependencies. > > There is a whole community adding features and documenting implications > and > > nuances. > > It is true that there wasn't a standard before Bundler. What I think, > and I guess most people will disagree with me, is that even though > Bundler was imposed upon every Rails developer, it doesn't mean it is > the standard for the rest of the Ruby community. Sure, I could go > along with the masses and adopt Bundler, but it feels wrong because it > is way out of my workflow. Bundler is a very big dependency, I don't > like the idea of it being imposed on me. Just for reference, this is > the tool we use for managing dependencies at the company I work for: > https://github.com/twpil/dep > > > It makes sense for heroku to drop their proprietary tool and go with the > > common one, no? > > That way they can dedicate their resources on other great stuff to give > to > > us. > > It may makes sense for Heroku, I really don't know if they will lose > clients by dropping support for the .gems manifest. I don't have the > power to avoid that from happening, sadly. If it were up to me, I > would stick to the minimalism of the .gems manifest and also support > Gemfile, given that most of the applications deployed to Heroku are > built with Rails. > > Thanks! > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
