From: Intransition Date: 2010-05-18T23:43:55+09:00 Subject: Re: Bundler Groups On May 17, 12:12 pm, Vinícius Baggio Fuentes wrote: > I don't know, I have the same feeling. Also, even if you're in a production > environment and only do Bundler.require(:default, :production), for example, > other group's gem are still needed to be installed, which is something I > don't like very much (although it is necessary, according to Yehuda Katz > [1]) > > [1]:http://yehudakatz.com/2010/05/09/the-how-and-why-of-bundler-groups/ According to the article it is to resolve dependencies correctly --in case you do use those other groups. Which I suppose makes sense, though I would think all it really needs it the gemspec, but I imagine if you have to get the gemspec you might as well get the whole package too (since the gemspec is in the package). Considering the examples given in that article, I wonder if it isn't getting confused with *optional dependencies*. For example, database adapters are generally optional. The article says Rails puts mysql and pg in a db group, but why would they not be in their own groups? Why would I want both installed in on a production machine to begin with? Doesn't make sense to me. And if you go so far as to put them in their own groups, such that one would then need to say 'bundle install -- without pg --without mysql ..." Isn't it just easier to install the gem you need yourself? I think maybe is should be '--with' rather than '--without'. Perhaps that indicates there are two types of groups: "recommend" which will be installed unless omitted via --without, and "suggest" which are only installed if specified using --with. Looking at Rails own Gemfile, it has " if RUBY_VERSION < '1.9' " and " if EVN['CI'] " conditions all over the place. With conditions like that, the Gemfile changes depending on what system I am running on. I guess that's the whole point when using 'bundle install'. But something about that doesn't sit quite right with me --maybe because it isn't actually declarative. In other words I can't query the configuration and ask it what gems we need when installing on a 1.9 system vs. a 1.8 system? And that leads to wondering about the tie-in to RubyGems itself. If I decide to bundle my application up as an actual gem, how do I describe dependencies to it? In the same old manner --knowing nothing about the Gemfile? That's not very DRY. The more I think about it, the more it seems like Bundler might be trying to do too much, and too cutoff from RubyGems proper. It's is trying to do some of the job of a tool like Capistrano, which is designed to manage deployments. And it's trying to do some sort of vendoring by allowing git repos to be dependencies. And it's trying to go handle optional dependencies, but in a rather poor way I think. And none of this is privy the RubyGems in order for it to build gems that take these things into account.