Re: Bundler Groups

On May 17, 12:12=A0pm, Vin=EDcius Baggio Fuentes <[e-mail]>
wrote:
> I don't know, I have the same feeling. Also, even if you're in a producti=
on
> environment and only do Bundler.require(:default, :production), for examp=
le,
> 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.