I don't want to play anything down here, but:

Nigel Kendrick wrote:

different passenger setup instructions on various sites (and yet more instructions via the installer itself)

The canonical installation instructions have always worked great and I've never understood the necessity to have extra ones for specific distros (at least for people knowing a little bit about unix/apache), of course, ymmv.

and Gem's refusal to update without some brute force

I don't want to seem overly pedantic, but debian/ubuntu has a bad habit of f*cking with every third-party package management (CPAN, gem, whatever the python one was, and so on), I've had no problems whatsoever with it on OS X and gentoo. I know it doesn't solve your problem, but it's one I see in the debian/ubuntu camp, not on our side (the inflexibility of the gem installation that is, not the version hell, which is another problem).

Anyway, that's my rant over! You can be assured that should I go ahead using ChiliProject I will 'give back' where I can

Even if you don't, it would be helpful if you documented the roadblocks you hit instead of "just ranting" (which you're totally free to do, it's just not that constructive :-) ), we do have installation instruction for Ubuntu, and any help improving them would be much appreciated!

but producing a VM or better packaged version will surely get more people 'into' the project.

AFAIK those are all thrid-party contributions in Redmine, and we don't have enough man-power at the moment to take care of such things ourselves. One more chicken-and-egg problem we're facing, I guess :-)

Felix,

Thanks for the constructive reply and also for not chewing me out too much!

Now that I have had a break I have completed the install and have Chiliproject up and running. Happy to produce a copy in a VM for you if you want.

Nigel

Nigel,

I am in the same boat... evaluated Redmine via VM (easy as pie) but would like to get a VM of ChiliProject to actually implement into production. Do you have a VMImage for public consumption? I just want an appliance with ChiliProject and Subversion in one image to first up and start using...

What kind of image do you need? vmware, openbox, xen, something else?

VMWare...

I'm in the same boat. I've tried on Unbuntu and Debian. Even tried to setup one replacing files frim hte Turnkey appliance for Redmine same issue trying to update gem. I'll take a virtualbox appliance if you have one otherwise I'll convert a vmware one.

Also with you permission I'll even post it on my website as a download if your worried about bandwidth.

Thanks!

Jim McAleer wrote:

Also with you permission I'll even post it on my website as a download if your worried about bandwidth.

It's free software, so feel free to make images and provide them for anyone else, putting a link in the wiki somewhere (maybe on the installation options page) wouldn't be a bad idea either, please mark it as an "external offering" rather than something ChiliProject provides though, I'd rather not want this to become a support forum/issue tracker for VM related problems.

Spent a good 2.5 hours or so getting Chili up and running on a fresh Ubuntu Server 11.04 VM very early this morning.

The `bundle` stuff is really screwy. I had to install dev packages for mysqlclient, sqlite3, postgresql, libmagick9-dev, etc., just to get `bundle install` to run without errors. Then when I added a plugin (one of mine from Redmine, that uses will_paginate) the only way I could get it to work was to edit my Gempack, add will_paginate, then run `bundle install` again to get it to work.

This isn't so much a problem with Chili (or Redmine), but with RoR apps in general. The Gems stuff either needs to go away, or be standardized and streamlined into a singularly maintained package and get away from the 80 versions of dozens of different gems. </rant>

My package list for 11.04:
apt-get install apache2 git subversion mysql-server libmysqlclient-dev libpq-dev libmagick9-dev imagemagick sqlite3 libsqlite3-dev ruby rubygems libmysql-ruby libopenssl-ruby1.8 librmagick-ruby

Other than several of those packages not being in the Wiki, i followed an amalgamation of the generic install guide, the general Linux install guide, and the Ubuntu 10.10 install guide.

If I get a wild hair, I'll start fresh and do a more documented install in a clean VM to nail down specific instructions and get a better wiki page up for 11.04.

Nick Peelman wrote:

The `bundle` stuff is really screwy.

Bundler is the new weapon of choice in the dependency hell: you specify your the gems/direct dependencies as well as the needed versions and so in your Gemfile, and bundle resolves the dependencies and versions, installs them as needed either globally or locally, can use the global gems or not, can vendor them, and in the end provides you with an environment in which only exactly the gems you have specified in just the right versions are apparent, even if newer/other/incompatible ones are installed on the machine too. That way you can for example have rails 2.3 be the default in one directory/subtree, rails 3 in another, and so on. In other words: you're gonna have to live with it.

Regarding your specific ubuntu install, if the gems needed exist as packages and those packages are installed, I suppose bundle will detect those and use those (I have no ubuntu handy, so no guarantee). In addition, you probably want to use either postgres or mysql or sqlite, you can deactivate the other two with the --without= flag, for example to use postgres: bundle install --without=mysql mysql2 sqlite (you will need to specify the --without option only once as bundler should remember it). Please note that there are 2 mysql groups: mysql and mysql2. mysql2 is the newer and preferred one, mysql is present for compatibility with distributions that ship the mysql gem but not the mysql2 one.

Regarding your plugin, you can add a Gemfile to it too, the ChiliProject Gemfile includes those automatically. In your case, a Gemfile with just gem "will_paginate" in it in the root directory of your plugin should be enough already. Remember to re-run bundle install in your ChiliProject directory after having installed the plugin.

Felix Schäfer wrote:

Bundler is the new weapon of choice in the dependency hell: you specify your the gems/direct dependencies as well as the needed versions and so in your Gemfile, and bundle resolves the dependencies and versions, installs them as needed either globally or locally, can use the global gems or not, can vendor them, and in the end provides you with an environment in which only exactly the gems you have specified in just the right versions are apparent, even if newer/other/incompatible ones are installed on the machine too. That way you can for example have rails 2.3 be the default in one directory/subtree, rails 3 in another, and so on. In other words: you're gonna have to live with it.

The problem is, Bundler (or rather the Gems its trying to install) are dependent upon development libraries, as i outlined above. Bundler does nothing to work on acquiring those. So you still have to be a complete and total Unix (or Windows, or Mac) nerd and know not only what to look for, but what to do with it once you find it.

I used to be a Windows admin and fought that kind of nonsense approach every day. Most people refer to it as DLL Hell. Same effect, different platform. The short version is if you're going to tie your app that closely to a third party library then the library should go IN your app. Not sure how feasible that is with RoR, but the point stands. This isn't a dig at you guys, Chili, Redmine, or anybody else; my plugins suffer the same stupidity. No matter how cool Rails may be as a platform, snafus like that make it come off smelling half-baked.

Regarding your specific ubuntu install, if the gems needed exist as packages and those packages are installed, I suppose bundle will detect those and use those (I have no ubuntu handy, so no guarantee). In addition, you probably want to use either postgres or mysql or sqlite, you can deactivate the other two with the --without= flag, for example to use postgres: bundle install --without=mysql mysql2 sqlite (you will need to specify the --without option only once as bundler should remember it). Please note that there are 2 mysql groups: mysql and mysql2. mysql2 is the newer and preferred one, mysql is present for compatibility with distributions that ship the mysql gem but not the mysql2 one.

Again, once you have all the libraries in place, Bundle works fine, even if the gems aren't there and it has to install them. Its all the pre-reqs that are the problem.

Regarding your plugin, you can add a Gemfile to it too, the ChiliProject Gemfile includes those automatically. In your case, a Gemfile with just gem "will_paginate" in it in the root directory of your plugin should be enough already. Remember to re-run bundle install in your ChiliProject directory after having installed the plugin.

So Bundle will recursively go through and find Gemfiles in plugins as well?

Nick Peelman wrote:

Felix Schäfer wrote:

Bundler is the new weapon of choice in the dependency hell: you specify your the gems/direct dependencies as well as the needed versions and so in your Gemfile, and bundle resolves the dependencies and versions, installs them as needed either globally or locally, can use the global gems or not, can vendor them, and in the end provides you with an environment in which only exactly the gems you have specified in just the right versions are apparent, even if newer/other/incompatible ones are installed on the machine too. That way you can for example have rails 2.3 be the default in one directory/subtree, rails 3 in another, and so on. In other words: you're gonna have to live with it.

The problem is, Bundler (or rather the Gems its trying to install) are dependent upon development libraries, as i outlined above. Bundler does nothing to work on acquiring those. So you still have to be a complete and total Unix (or Windows, or Mac) nerd and know not only what to look for, but what to do with it once you find it.

Well, problems with binary gems requiring the source/development versions didn't spring up with bundler, those were there before. In fact, bundler doesn't acquire anything, it just calls rubygems to install stuff, bundler scratches a different itch. Bundler provides a central place where you can/have to define all you dependencies (the Gemfile), you can specify versions (minor, major, exact, at least, at most, a range, and so on), bundler does all the resolving of dependencies and versions and provides rubygems with an exact list of gems to install/look for. In addition, bundler "protects" you from other versions of gems by "showing" only the gems in the versions it has selected when you run stuff.

The best scenario would be to have packages for ChiliProject. A packager can then point the package management tool of her distro of choice to the Gemfile, which then recognizes which other packages it needs, including the binary ones you then wouldn't have to compile, all good.

What you're saying essentially is that Firefox should package X, some nvidia and ati drivers for good measure and the glibc just to make sure it can run on any linux kernel.

I used to be a Windows admin and fought that kind of nonsense approach every day. Most people refer to it as DLL Hell. Same effect, different platform. The short version is if you're going to tie your app that closely to a third party library then the library should go IN your app.

No. External library. External means we don't want to be bothered with it, just use it, library means it has some interface that ideally stays over some time/versions, versions you can then specify in your Gemfile.

One more nail to the coffin: Those binary extensions causing you trouble, there'd have to either be some way to package binary stuff for like so many different platforms and have code select the right one at runtime, or have so many packaged versions of ChiliProject. You'd need at least one developer to take care of that. Or support only a small part of platforms now available. Not nice. (oh, and having one windows, one linux and one OS X isn't good enough, you have the different processor architectures to take care of, times so many different linux distributions, and so on). Personally, I'm sick of windows installation packages where I have to select the right one for either 32 or 64 bit (where the hell do I look that up again? Is this any less nerd-needing than installing devel packages?), win 7/Vista/XP/2003/2008 or whatever, and so on.

And not the same as dll hell. You have a tool to take care of fetching gems for you: rubygems, which linux distributions can hook their package manager into to install packaged gems if available. Rubygems also allows you to have multiple versions of the same gem installed, the problem here being that you could have programs just requesting the library without any version info and getting newer and incompatible gems than expected. Enter bundler, which allows you to isolate applications and show one application only a subset of installed gems, and now it's up to gem developers to follow semver and make sure their library API is stable through minor updates.

Not sure how feasible that is with RoR, but the point stands.

If you want to vendor them, i.e. want to throw in all gems into your app? No problem: bundle package should do the trick.

This isn't a dig at you guys, Chili, Redmine, or anybody else; my plugins suffer the same stupidity. No matter how cool Rails may be as a platform, snafus like that make it come off smelling half-baked.

Funny that you seem to be using some linux flavor and seem to be bitching about putting stuff in libraries so that you don't have to keep them in your app. Ever wondered what rpm, yum and apt do?…

Regarding your specific ubuntu install, if the gems needed exist as packages and those packages are installed, I suppose bundle will detect those and use those (I have no ubuntu handy, so no guarantee). In addition, you probably want to use either postgres or mysql or sqlite, you can deactivate the other two with the --without= flag, for example to use postgres: bundle install --without=mysql mysql2 sqlite (you will need to specify the --without option only once as bundler should remember it). Please note that there are 2 mysql groups: mysql and mysql2. mysql2 is the newer and preferred one, mysql is present for compatibility with distributions that ship the mysql gem but not the mysql2 one.

Again, once you have all the libraries in place, Bundle works fine, even if the gems aren't there and it has to install them. Its all the pre-reqs that are the problem.

Well, I guess we need more docs telling people that there probably are packaged versions of the binary gems available for their distro and that they don't need to compile them themselves? Maybe even list them so that you can just install them? :-)

Regarding your plugin, you can add a Gemfile to it too, the ChiliProject Gemfile includes those automatically. In your case, a Gemfile with just gem "will_paginate" in it in the root directory of your plugin should be enough already. Remember to re-run bundle install in your ChiliProject directory after having installed the plugin.

So Bundle will recursively go through and find Gemfiles in plugins as well?

Nope, but the ChiliProject Gemfile includes Gemfiles from vendor/plugins/* into itself, see source:/Gemfile#L67

Felix Schäfer wrote:

What you're saying essentially is that Firefox should package X, some nvidia and ati drivers for good measure and the glibc just to make sure it can run on any linux kernel.

hyperbole, but point taken. i guess the biggest problem lies with the fragility of the underlying libraries/gems/whatevers.

No. External library. External means we don't want to be bothered with it, just use it, library means it has some interface that ideally stays over some time/versions, versions you can then specify in your Gemfile.

One more nail to the coffin: Those binary extensions causing you trouble, there'd have to either be some way to package binary stuff for like so many different platforms and have code select the right one at runtime, or have so many packaged versions of ChiliProject. You'd need at least one developer to take care of that. Or support only a small part of platforms now available. Not nice. (oh, and having one windows, one linux and one OS X isn't good enough, you have the different processor architectures to take care of, times so many different linux distributions, and so on). Personally, I'm sick of windows installation packages where I have to select the right one for either 32 or 64 bit (where the hell do I look that up again? Is this any less nerd-needing than installing devel packages?), win 7/Vista/XP/2003/2008 or whatever, and so on.

OS X solved the problem of multiple architectures (correctly, imho) via fat binaries. my point still stands: you "require" version x of a plugin, library, whatever. your program shouldnt be looking to a common space for it. again, its a failing of Ruby, Rails, and the paradigm created by gems.

And not the same as dll hell. You have a tool to take care of fetching gems for you: rubygems, which linux distributions can hook their package manager into to install packaged gems if available. Rubygems also allows you to have multiple versions of the same gem installed, the problem here being that you could have programs just requesting the library without any version info and getting newer and incompatible gems than expected. Enter bundler, which allows you to isolate applications and show one application only a subset of installed gems, and now it's up to gem developers to follow semver and make sure their library API is stable through minor updates.

so bundler effectively does sandboxing (or a form of it). thats been tried, with moderate success, to fix dll hell too.

i would also argue that devs using gems should be standing on gem writers a little more firmly to NOT do stupid shit that causes these kinds of headaches on minor versions. but i have my own battles to fight.

Funny that you seem to be using some linux flavor and seem to be bitching about putting stuff in libraries so that you don't have to keep them in your app. Ever wondered what rpm, yum and apt do?…

i use linux. i dont particularly like linux. package tools only serve to mask the mess that is linux applications with yet another layer (or 10) of complexity. no tools or movements exist, that im aware of, that attack the underlying problems of linux and linux development, many of which are shared by ruby and rails dev.

Well, I guess we need more docs telling people that there probably are packaged versions of the binary gems available for their distro and that they don't need to compile them themselves? Maybe even list them so that you can just install them? :-)

again...the gems...are...not...the...problem. its all the dev libraries needed before the gems can be installed, that go undocumented.... when you provide a guide, and somebody offers feedback, AND extends an offer to bang out a NEW guide for a newer Ubuntu, being less of a dick about it might serve everybody's purpose a little better. you want specific versions of gems. fine. i get that. you want to use bundler. fine. i get that. all i was trying to do was offer insights into what i went through getting up and running on 11.04. bundler didnt make it easier, it only added one more thing that had to be made happy. i still had to do the same amount of legwork to get going as i would have been doing sans bundler. its a sanity check, and thats appreciated, but both it and rubygems are pretty useless when it comes to taking a vanilla Ubuntu install and making it a suitable rails host. having a more comprehensive list of whats required would have shortened my process by at least an hour.

Nope, but the ChiliProject Gemfile includes Gemfiles from vendor/plugins/* into itself, see source:/Gemfile#L67

interesting. its still a convoluted, ridiculous mess, but the hell if we're going to see a clone in .NET, PHP, or anything that has a documented and stable backend, so here we are, stuck trying to make this a less hellish task for anybody who didnt spend their teenage weekends in front of a keyboard.

Does any one have a vmware or virtualbox image they could give me. I'd like to make it available or everyone. Chiliproject seems to be much faster than redmine. I'm 4 days and still stuck on the bundle gem file error.

Well I completed the install. Holy cow! It wasn't easy being a rookie at linux but i made it. Not only will I provide a link but i will document the script, publish it on my site and give it to turnkey so thay can publish and keep up with any changes. I'll do this right after i create a few more virtuals just to make sure I have everything right.

Woooohooooo!!!!!

Spurred on by this thread and others in the tracker/irc I thought I'd have a go at making a usable vbox image for people to test against.

This is my first time doing so and it's definitely not something you want to put in production, but I'll iterate over it a few times to see if I can make it any better:

http://sikhnerd.com/chiliappliance/

This is CentOS 6 netinstall with all the defaults. I mostly followed my tutorial with whatever minor adjustments necessary to make it work on CentOS 6 (I'll add that tutorial to my blog and this site soon).

You should be able to import this appliance into virtualbox, login as root (the info is printed to screen on bootup), run cpip and visit that ip in your browser. The only change you may need to make in the virtualbox settings will be the network setup from host-only to bridge mode.

Any feedback would be greatly appreciated, I'll probably even have v0.2 uploaded there before you read this :)

v0.2 has been uploaded, it has some minor improvements. Once I get some feedback I'm debating what direction I want to go with it from here.

Nick Peelman wrote:

Felix Schäfer wrote:

Well, I guess we need more docs telling people that there probably are packaged versions of the binary gems available for their distro and that they don't need to compile them themselves? Maybe even list them so that you can just install them? :-)

when you provide a guide, and somebody offers feedback, AND extends an offer to bang out a NEW guide for a newer Ubuntu, being less of a dick about it might serve everybody's purpose a little better.

That came over horribly wrong (and I should have guessed as much after all the decoupled vs. integrated libraries diatribe) and I'm really sorry I offended you. What I meant to say was that you could write down your experience in a how-to so that it's easier for the next guy. I'll be happy to help you in any meaningful way, e.g. by trying it out in a VM.

OS X solved the problem of multiple architectures (correctly, imho) via fat binaries.

Indeed, not that of the libraries though, as you have to package more or less everything not already provided by the OS into your program package.

I could argue that linux distributions solve both the architecture and the library and dependency problems by providing you a single tool to resolve those for you, for that to work well, you'd need to only install stuff through the package manager though, and that's not always something easy to do.

my point still stands: you "require" version x of a plugin, library, whatever. your program shouldnt be looking to a common space for it. again, its a failing of Ruby, Rails, and the paradigm created by gems.

And not the same as dll hell. You have a tool to take care of fetching gems for you: rubygems, which linux distributions can hook their package manager into to install packaged gems if available. Rubygems also allows you to have multiple versions of the same gem installed, the problem here being that you could have programs just requesting the library without any version info and getting newer and incompatible gems than expected. Enter bundler, which allows you to isolate applications and show one application only a subset of installed gems, and now it's up to gem developers to follow semver and make sure their library API is stable through minor updates.

so bundler effectively does sandboxing (or a form of it). thats been tried, with moderate success, to fix dll hell too.

It does, which gives you the advantage of a shared library space while still retaining isolation. Each dev has to provide a Gemfile for that to work well though.

i would also argue that devs using gems should be standing on gem writers a little more firmly to NOT do stupid shit that causes these kinds of headaches on minor versions. but i have my own battles to fight.

That's how you don't need to package X, glibc or whatever with firefox, because the points of contact are stable. The ruby space is a very agile-oriented one though, and API stability doesn't weigh much with many devs, there's already been some projects where this caused a lot of pain and backfire though, so we might see a little more stability in the future. I personally would be happy if devs would adhere to semantic versioning (we're trying to) so that you can at least know/guess when to expect stability and when to expect possible breakage.

Nope, but the ChiliProject Gemfile includes Gemfiles from vendor/plugins/* into itself, see source:/Gemfile#L67

interesting. its still a convoluted, ridiculous mess, but the hell if we're going to see a clone in .NET, PHP, or anything that has a documented and stable backend, so here we are, stuck trying to make this a less hellish task for anybody who didnt spend their teenage weekends in front of a keyboard.

At least ChiliProject doesn't require CPAN *coughs*

Felix Schäfer wrote:

That came over horribly wrong (and I should have guessed as much after all the decoupled vs. integrated libraries diatribe) and I'm really sorry I offended you. What I meant to say was that you could write down your experience in a how-to so that it's easier for the next guy. I'll be happy to help you in any meaningful way, e.g. by trying it out in a VM.

Yeah, I probably should have let most of this slide, but as is too often the case, the day job was proving frustrating and I took your snark a bit too personally. My apologies as well. A better tutorial / guide / package list for a bare-bones 11.04 install will come this week.

OS X solved the problem of multiple architectures (correctly, imho) via fat binaries.

Indeed, not that of the libraries though, as you have to package more or less everything not already provided by the OS into your program package.

All the libraries (frameworks) in OS X are also compiled as "fat" as well. The various pieces of the Cocoa framework are as universal as the apps that depend on it to function. This just proves that it's possible though, the likelihood of such a paradigm having any serious penetration in the Linux world (and/or Ruby world) at this point is slim.

I could argue that linux distributions solve both the architecture and the library and dependency problems by providing you a single tool to resolve those for you, for that to work well, you'd need to only install stuff through the package manager though, and that's not always something easy to do.

Well I will admit, that the discovery of Apt (and my subsequent loves of Debian, and later Ubuntu) made becoming a Linux geek substantially easier, and let me get into USING Linux while forcing me into manually-installing-library-Hell fewer and fewer times as the distributions have matured. Its when you throw in tools like rubygems that don't leverage it properly, mostly because the Linux world can't get its ass in gear and standardize on a package tool / format, though Ubuntu has done more on this front than any other distro has been able to do. There's still the root problem that packaging tools only serve to hide; the eventually I hope some of the backend nightmare complexity can be wrapped up into larger, sweeping, stable libraries/frameworks/etc. Not holding my breath, but it would be greatly nice.

It does, which gives you the advantage of a shared library space while still retaining isolation. Each dev has to provide a Gemfile for that to work well though.

Which goes back to the consistency problems at the root of any and all debates similar to this one. By its very nature Linux is going to be and forever remain a nightmare to manage. Even if a standard is reached at some point, there are too many packages that will be built improperly, or not follow it. HP is a billion dollar company, producing printer drivers for MILLIONS of machines, yet they can't find an engineer talented enough to properly maintain installer packages well enough to not cause grief and nightmares like the hour I spent this weekend trying to reinstall a printer on my in-laws' Dell (long story...they got a new macbook, the printer became a network printer on the new Time Capsule, hell ensued).

That's how you don't need to package X, glibc or whatever with firefox, because the points of contact are stable.

And that was the source of my "hyperbole much?" comment. :) In almost any other dev environment you don't have this problem.

The ruby space is a very agile-oriented one though, and API stability doesn't weigh much with many devs, there's already been some projects where this caused a lot of pain and backfire though, so we might see a little more stability in the future. I personally would be happy if devs would adhere to semantic versioning (we're trying to) so that you can at least know/guess when to expect stability and when to expect possible breakage.

Yep.

At least ChiliProject doesn't require CPAN

That's something. One afternoon this week I'll pound out a fresh VM and start tinkering with a wiki page for 11.04. I created the (dead) link on the Linux installer page already.

https://www.chiliproject.org/projects/chiliproject/wiki/Installation_on_Ubuntu_11_04

It needs some formatting help, and probably another couple of people to run through with testing it. But following those instructions I was able to run right through and get a vanilla ChiliProject install up and out the door in about 15 minutes. YMMV. Interested in any and all feedback.

Nick Peelman:

Thanks for writing that guide. I have a set of moonshine and puppet scripts I've used to set up and configure ChiliProject/Redmine on Ubuntu. If I get the time I'll try to compare my code to your guide (my code has been updated from a few dozen installs).

Muntek:

How hard is it to build a vbox image? I could install Debian and Ubuntu and fire my moonshine scripts at it. Any special tweaking you did (e.g. iptables, documentation, etc).

Eric Davis

Eric Davis wrote:

Muntek:

How hard is it to build a vbox image? I could install Debian and Ubuntu and fire my moonshine scripts at it. Any special tweaking you did (e.g. iptables, documentation, etc).

Eric Davis

Extremely easy. All I did was install the OS, setup things how I want it and add a couple tiny extra bits. I haven't done a lot of documentation, other than the stuff that prints to the console upon boot up, which gives all the basic instructions, contact info, and how to use it. The small handful of people who have used my appliance have told me that was more than sufficient. I created a couple bash scripts to make things easier for users (see: cpip in my images) but nothing else that was a lot of work. As long as you setup the network interface to use DHCP, users can let virtualbox handle all the networking, which is a huge win.

Iptables I did nothing beyond the CentOs defaults, and open up port 80. Later versions I'm going to add some more helper scripts and lock down the install until I can safely recommend someone to use my appliance in production. I'd love to get any actual feedback before moving forward.

Nick Peelman wrote:

https://www.chiliproject.org/projects/chiliproject/wiki/Installation_on_Ubuntu_11_04

It needs some formatting help, and probably another couple of people to run through with testing it. But following those instructions I was able to run right through and get a vanilla ChiliProject install up and out the door in about 15 minutes. YMMV. Interested in any and all feedback.

At least functionally it's sound, just applied it to a vanilla ubuntu server 11.04 VM and apart from the few typos/bugs I corrected, everything worked as expected.

Here's a easy install on a Turnkey virtual machine. http://jim.mcaleerblog.com/archives/507

Any Chiliproject 2.2 VMWare images (or anything I can convert to VMWare)?

Hi there,

I've been trying to install v2.2.0 for days on WinXPSP3 with Ruby 1.8.7. Now I'm loosing the will to install because finally it ended up in the for me unsolvable error:

C:\...>bundle exec rake db:migrate RAILS_ENV=development
!!! The bundled mysql.rb driver has been removed from Rails 2.2. Please install the mysql gem and try again: gem install
rake aborted!
no such file to load -- mysql

Tasks: TOP => db:migrate => environment
(See full trace by running task with --trace)

*** LOCAL GEMS ***

actionmailer (2.3.14, 2.3.5)
actionpack (2.3.14, 2.3.5)
activerecord (2.3.14, 2.3.5)
activeresource (2.3.14, 2.3.5)
activesupport (2.3.14, 2.3.5)
bundler (1.0.18)
cgi_multipart_eof_fix (2.5.0)
coderay (0.9.8)
edavis10-object_daddy (0.4.3)
fastercsv (1.5.4)
gem_plugin (0.2.3)
i18n (0.4.2)
metaclass (0.0.1)
mocha (0.10.0)
mongrel (1.1.5 x86-mingw32)
mongrel_service (0.3.4 i386-mswin32)
mysql (2.8.1 x86-mingw32)
rack (1.1.2, 1.1.0, 1.0.1)
rails (2.3.14, 2.3.5)
rake (0.9.2, 0.8.7)
rdoc (3.9.4)
rmagick (2.12.0 mswin32)
ruby-openid (2.1.8)
rubytree (0.5.3)
shoulda (2.10.3)
win32-service (0.5.2 mswin32)

I've tried MySQL Versions 5.0 and 5.1 and followed the "libmysql.dll" hint. Overall I spend 1.5 days to browse all the pages which cover this particular problem, but nothing worked for me.

Bad luck! I'd give it a fair chance but I couldn't until now.

Best regards
Jörg