# Bundler Groups

**URL:** <https://www.ruby-forum.com/t/bundler-groups/188745>\
**Category:** Ruby\
**Created:** [May 17, 2010, 5:55pm UTC](https://www.ruby-forum.com/t/bundler-groups/188745 "2010-05-17T17:55:44Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 17, 2010, 5:55pm UTC](https://www.ruby-forum.com/t/bundler-groups/188745/1 "2010-05-17T17:55:44Z")

</div>

I’d like to ask a more specific question about Bundler, pertaining to  
it’s concept of groups.

Do others see this as being truly useful? Or do you agree with me that  
it will prove to be mostly a YAGNI, and in come cases could even have  
bad consequences, e.g. a requirement was in the test group that  
actually should have been in the production group.

Or do you see truly important uses for them, and now that we have  
them, would be too inconvenient to live without?

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 17, 2010, 6:12pm UTC](https://www.ruby-forum.com/t/bundler-groups/188745/2 "2010-05-17T18:12:43Z")

</div>

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 K.  
[1](http://yehudakatz.com/2010/05/09/the-how-and-why-of-bundler-groups/))

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 18, 2010, 4:44pm UTC](https://www.ruby-forum.com/t/bundler-groups/188745/3 "2010-05-18T16:44:19Z")

</div>

On May 17, 12:12 pm, Vinícius Baggio F. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
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 K.  
> [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.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 18, 2010, 5:08pm UTC](https://www.ruby-forum.com/t/bundler-groups/188745/4 "2010-05-18T17:08:20Z")

</div>

On Tue, May 18, 2010 at 4:43 PM, Intransition [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> 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.

That’s talking about Rails itself. If you are contributing to the  
Rails codebase you certainly want to run its test suite. In particular  
the suite of Active Record, which involves SQLite, MySQL, and  
PostgreSQL.

A Rails application has in its generated Gemfile only the adapter of  
the database it has been generated for.

On the other hand, if you want to patch the Rails API via docrails, or  
are working on guides, you do not need to setup the databases, nor to  
install the database adapters. In that case you may tell bundler not  
to include that group and you’re done. That’s a use case for groups.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 18, 2010, 7:40pm UTC](https://www.ruby-forum.com/t/bundler-groups/188745/5 "2010-05-18T19:40:03Z")

</div>

On May 18, 11:04 am, Xavier N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> the suite of Active Record, which involves SQLite, MySQL, and  
> PostgreSQL.

I see. So ActiveRecord’s tests are designed to test against these  
three databases. How are the other adapters tested? Also shouldn’t  
this be part of ActiveRecord’s Gemfile? And what if you have only one  
of these databases on your system, or perhaps I am only concerned with  
an issue in the mysql adapter. That would indicate a need to select  
among them.

And that makes me wonder how these group selections filter down to  
their dependencies. I take it the --without selections applies to all  
of them?

> A Rails application has in its generated Gemfile only the adapter of  
> the database it has been generated for.

Ok. That make sense.

> On the other hand, if you want to patch the Rails API via docrails, or  
> are working on guides, you do not need to setup the databases, nor to  
> install the database adapters. In that case you may tell bundler not  
> to include that group and you’re done. That’s a use case for groups.

I can see that. But it doesn’t seem like a strong case. I mean, is it  
worth remembering this group just to avoid these two dependencies b/c  
you only plan to be doing doc work? Might it not just have a mode to  
ask you which dependencies you want?

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 18, 2010, 7:57pm UTC](https://www.ruby-forum.com/t/bundler-groups/188745/6 "2010-05-18T19:57:02Z")

</div>

On Tue, May 18, 2010 at 7:39 PM, Intransition [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> I see. So ActiveRecord’s tests are designed to test against these  
> three databases. How are the other adapters tested?

The rest of adapters have their own projects. Rails core is not tested  
against Oracle, say.

> Also shouldn’t  
> this be part of ActiveRecord’s Gemfile?

There’s only one Gemfile in Rails.

> And what if you have only one  
> of these databases on your system, or perhaps I am only concerned with  
> an issue in the mysql adapter. That would indicate a need to select  
> among them.

One should not submit a patch or touch the core without first running  
the test suite. Technically you can still comment the line of the  
Gemfile that requires the Postgres driver, but you get some vinegar  
there :).

> And that makes me wonder how these group selections filter down to  
> their dependencies. I take it the --without selections applies to all  
> of them?

The dependency graph is computed against everything no matter what.  
That’s why even if you do not install something because of --without,  
bundler will fetch (but not install) the gem. Goal is to compute a gem  
set that is consistent across environments.

> I can see that. But it doesn’t seem like a strong case. I mean, is it  
> worth remembering this group just to avoid these two dependencies b/c  
> you only plan to be doing doc work? Might it not just have a mode to  
> ask you which dependencies you want?

It is a feature you of course can ignore. It is there because the use  
cases where considered important enough to have it implemented.