Bundler Groups

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?

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]: The How and Why of Bundler Groups

···

On Mon, May 17, 2010 at 12:55 PM, Intransition <transfire@gmail.com> wrote:

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?

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.

···

On May 17, 12:12 pm, Vinícius Baggio Fuentes <vinibag...@gmail.com> 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]:The How and Why of Bundler Groups

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.

···

On Tue, May 18, 2010 at 4:43 PM, Intransition <transfire@gmail.com> 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.

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

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?

···

On May 18, 11:04 am, Xavier Noria <f...@hashref.com> wrote:

On Tue, May 18, 2010 at 4:43 PM, Intransition <transf...@gmail.com> 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.

···

On Tue, May 18, 2010 at 7:39 PM, Intransition <transfire@gmail.com> wrote: