ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Why not a Gemfile ?

Added by Cyril Mougel at 2011-03-08 10:19 am

Chiliproject has no Gemfile. Bundler is a really great tool to manage and sandox your gem. Bundler can work with a Rails 2.3.5 application. So there are any reason to not have a Gemfile in Chiliproject ?


Replies (4)

RE: Why not a Gemfile ? - Added by Felix Schäfer at 2011-03-08 11:00 am

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

RE: Why not a Gemfile ? - Added by Gregor Schmidt at 2011-03-08 01:01 pm

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.

RE: Why not a Gemfile ? - Added by Eric Davis at 2011-03-09 12:42 am

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

RE: Why not a Gemfile ? - Added by Gregor Schmidt at 2011-03-09 06:02 am

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

(1-4/4)