I think no other than that we haven't converted yet :-)

We already created a working Gemfile on https://github.com/finnlabs/chiliproject-gemfile/. The ci-branch of that repository is used on ci.chiliproject.org to set up the gem environment. This could be used as a starting point.

When switching to bundler we need to consider, that one single Gemfile should cover all optional dependencies and it needs to work for all Ruby versions/interpreters that are supported. This was a major challenge when compile the above mentioned Gemfile.

Also, bundler supports groups, but by default always installs all groups. This is probably not needed, since you will probably only need 1 database adapter and not 4. This needs to be considered when writing howtos and installation guides.

There were two reasons we haven't switched to Bundler:

1. Redmine 1.0 was in the process of being released so we were locked to Rails 2.3.5. At that time Bundler was pre-1.0 so it was going through a lot of changes and required some hacks to work with 2.3.5.
2. ChiliProject 1.x is still locked to Rails 2.3.5 for compatibility and ease of migration from Redmine.

Now that Bundler is stable and works with 2.3.latest (point 1) and if we are talking about ChiliProject 2.x, I think setting up bundler is a good idea.

Gregor Schmidt wrote:

Also, bundler supports groups, but by default always installs all groups. This is probably not needed, since you will probably only need 1 database adapter and not 4. This needs to be considered when writing howtos and installation guides.

Any way to have different Gemfiles for the databases/interpretors and have people copy the ones they want? Like how we have database.yml.mysql right now.

Eric Davis

Eric Davis wrote:

Any way to have different Gemfiles for the databases/interpretors and have people copy the ones they want? Like how we have database.yml.mysql right now.

I think we should try to avoid having multiple Gemfiles. It is one of bundlers core features to resolve all dependencies and make sure, that everybody is running the very same set of gems (incl. their versions) - no matter if your in production or development, on mysql or postgres. By using just one Gemfile with a sensible set of optional groups we should be able to support all official configurations. Also see http://gembundler.com/rationale.html#faq-3 why using groups is a good idea.

If it really doesn't work out using a single Gemfile, we can still consider to switch to multiple ones.

I mainly wanted to point out, that we need to make sure, that our documentation and our support staff is aware of bundler's way to handle optional dependencies.

Gregor