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.
Script to correctly configure bundler (Feature #522)
Description
There should be a script which interactively checks dependencies and asks the user how to configure bundler.
History
Updated by Eric Davis at 2011-07-15 10:07 pm
I don't know about this. I've always hated how complex our installation is, bundler will help out quite a bit once everything is fully moved over (plugins) and we've got the versions figured out.
Updated by Holger Just at 2011-07-25 05:34 pm
The script was originally intended to check that we have
- a supported ruby version
- a supported version of rubygems and bundler
It then asks the user which groups she wants to install (possibly checking dependencies like compilers or headers or proposing matching packages from the systems package manager). After that, bundler would be invoked with the default Gemfile.
However that might not be a really good ideas as this script could become arbitrarily complex and could also not properly deal with the requirements of different systems. Thus it might be better to just improve our documentation to lead users to properly install Bundler and all required dependencies.
But we still have two things to consider here:
1. Bundler's original scope is to define exact dependencies of top of rubygems. That's why they recommend to commit the Gemfile.lock into Git.
2. ChiliProject is intended to be run on a variety of systems
It has been shown that Bundler's Gemfile syntax isn't as expressive as we would like it to have. Also it's hard to define dependencies which suit everybody (e.g. rmagick on old systems (like Lenny) vs. new systems (like Fedora), mysql or sqlite versions also differ).
Thus, it might be feasible to use the Gemfile as a kind of launcher and include other system specific Gemfiles for users who want to install just their OS packages and don't want to have a compiler. That way, we could have one Gemfile for each distribution and somehow instruct bundler to use those. Users who are good with a compiler can use our common Gemfile
What do you think about that idea?
- Assignee deleted (
Holger Just)
Updated by Eric Davis at 2011-07-25 10:56 pm
Holger Just wrote:
Thus, it might be feasible to use the Gemfile as a kind of launcher and include other system specific Gemfiles for users who want to install just their OS packages and don't want to have a compiler. That way, we could have one Gemfile for each distribution and somehow instruct bundler to use those. Users who are good with a compiler can use our common Gemfile
What do you think about that idea?
Maybe, I'd have to see the complexity before I could make a decision. It's too bad Bundler doesn't let you remove and re-version gems. Then we could tell a Debian user to download Gemfile.debian and Gemfile.mysql into config/bundlers and have it "just work for them". Maybe that is the way we go and just have the core Gemfile be as minimal as possible. I don't know...
Updated by John Yani at 2012-03-24 09:14 pm
Just one suggestion for a gem installation rake task: do not include plugins' gemfiles in the main gemfile. It will generate an error:
You cannot specify the same gem twice with different version requirements.
if plugin also requires the same gem as Chiliproject. Better approach would be just to use bundler command in each plugin directory with --path pointing to chiliproject/vendor/bundle.
Also posted to Redmine: http://www.redmine.org/issues/10474
Updated by Felix Schäfer at 2012-03-25 07:32 am
John Yani wrote:
Just one suggestion for a gem installation rake task: do not include plugins' gemfiles in the main gemfile. It will generate an error:
You cannot specify the same gem twice with different version requirements.
if plugin also requires the same gem as Chiliproject.
This is a problem with bundler (and one others have too, see Point 3 in http://alexbcoles.com/code/2012/03/20/bundler-pain-points.html).
Better approach would be just to use bundler command in each plugin directory with --path pointing to chiliproject/vendor/bundle.
I don't think this would write the gems need by the plugins to the Gemfile.lock, i.e. they wouldn't be available to the running app, so this won't work.