From my point of view, ruby developers are not the most who use this system. Some systems, like FreeBSD have different approach than "gem install" - they have ports from which everything should be installed. Those who mix the canonical way and "linux" one (are ony other) can have lot's of troubles while managing this system in future. However separate gem for newbies should be usefull. Just for me - the current distribution way is good enough.

P.S.
The only I'd point to is Feature #298

Anton Lukashev wrote:

Some systems, like FreeBSD have different approach than "gem install" - they have ports from which everything should be installed. Those who mix the canonical way and "linux" one (are ony other) can have lot's of troubles while managing this system in future.

Well, perhaps, but that's not really a ChiliProject-specific issue. See, for instance, http://stackoverflow.com/questions/5108437/install-ror-on-debian-squeeze

The only I'd point to is Feature #298

Feature #298 seems sensible to me, but its obviously about improving the way plugins are managed as gems, rather than about packaging ChiliProject itself as a gem.

I guess I should file a new feature request :)

Thanks for your help :)

Sam Kuper wrote:

I guess I should file a new feature request :)

Done: #334

Sam Kuper wrote:

Anton Lukashev wrote:

Some systems, like FreeBSD have different approach than "gem install" - they have ports from which everything should be installed. Those who mix the canonical way and "linux" one (are ony other) can have lot's of troubles while managing this system in future.

Well, perhaps, but that's not really a ChiliProject-specific issue. See, for instance, http://stackoverflow.com/questions/5108437/install-ror-on-debian-squeeze

I just wanted to point that most of unix-like systems have their native (canonical) aproaches for maintening installed software. But as you menshioned (and I agree with that) this lies beyond this topic.

Oh and btw, in FreeBSD redmine being installed from ports comes fully workable, so that only you need is to start your favourite web service and have fun.

I'm open to the idea of a gem package but I've seen other applications that are distributed as gems and saw they had some complex code or installation to support it. I don't even know if Passenger or mongrel can host an application as a gem without having to create a few bootstrap files (like config.ru for Sinatra).

If someone wants to prototype this and report back with some ideas about how "much" of ChiliProject could be packaged into a gem, I'd be happy to look at it.

(Side note: I've thought of creating a simple gem/script to help install all of ChiliProject's dependencies. Kinda like bundler + prompts about if you want to use sqlite/mysql/psql and installing the gems they require.)

Eric Davis

Eric Davis wrote:

(Side note: I've thought of creating a simple gem/script to help install all of ChiliProject's dependencies. Kinda like bundler + prompts about if you want to use sqlite/mysql/psql and installing the gems they require.)

Correct me if I'm wrong. You are talking about something like "checksetup.pl" distributed by bugzilla? (This script checks for installed perl modules and does compiling of templates, etc...)

My main purpose in opening the thread was to publicly ask if it was a request that had already been made; and if not, one that might be worth making. The answers (both from Anton's reply and from some subsidiary Googling) appeared to be "no" and "yes", respectively.

I'm not sure if there's a way to close a discussion thread in ChiliProject, but since I've already created a feature request for this (as mentioned above), wouldn't it be best to discuss the merits of the request itself over there? At least, if we're to avoid anti-patterns...

Thanks all,

Sam

Ah, just saw Eric's comment on the request, suggesting we discuss it here instead. Oops!

Sam Kuper wrote:

Ah, just saw Eric's comment on the request, suggesting we discuss it here instead. Oops!

On reflection, though, my feeling is still that to preserve the aim of the thread (which has already been fulfilled) and the aim of the feature request (which hasn't), it probably makes more sense to consider this thread closed and to discuss the feature request below the feature request.

Shall we have a vote? :p

Sam Kuper wrote:

On reflection, though, my feeling is still that to preserve the aim of the thread (which has already been fulfilled) and the aim of the feature request (which hasn't), it probably makes more sense to consider this thread closed and to discuss the feature request below the feature request.

"Make sure the bug tracker doesn't turn into a discussion forum" -- http://producingoss.com/en/bug-tracker.html#bug-tracker-mailing-list-interaction

I'd rather use the forums as a way to discuss and explore ideas and the issue tracker as a way to review the work and as actual tasks to do.

Eric Davis

Eric Davis wrote:

"Make sure the bug tracker doesn't turn into a discussion forum" -- http://producingoss.com/en/bug-tracker.html#bug-tracker-mailing-list-interaction

I'd rather use the forums as a way to discuss and explore ideas and the issue tracker as a way to review the work and as actual tasks to do.

Interesting link; thanks for explaining your approach :)

the same gem would be used for rpms, so you would have quite easy distro support (at least for rpm distros, no idea about debian)