On Tue, November 20, 2012 06:53, C. L. Martinez wrote:
On Tue, Nov 20, 2012 at 11:23 AM, Phil Dobbin bukowskiscat@gmail.com wrote:
On 11/20/2012 08:39 AM, C. L. Martinez wrote:
Hi all,
Somebody knows if exists some rpm package for ruby rails??
Normally, rubygems is the way to go to install Rails.
Cheers,
Phil...
Sure, but how can I update rubygems installed in one system??
The main problem with RHEL and Ruby on Rails is that the version of Ruby available for EL6 from reputable repositories is too old. RoR 3.2 can get by on 1.8.7 but support for Ruby versions prior to 1.9.3 is being dropped in the forthcoming RoR v4 release. Thus, a RHEL/CentOS rpm package for Rails really will not give you much, if anything.
I suggest that you investigate both RBENV and RVM as alternatives to using the rpm packaged Ruby. I advise you consider that for RoR projects the Bundler gem is the preferred way of installing and managing project specific packages, including Rails itself.
The down side to this approach is that your production servers need to have development tools installed to build the Ruby interpreter and the support gems. The up side is that you can version specific ruby vms and gemsets on a project by project basis.
https://github.com/sstephenson/rbenv https://rvm.io/ http://gembundler.com/
I used rvm almost from its inception but have recently changed to rbenv as this has a much smaller footprint on the user's environment. But both are excellent products. If you are installing RoR for a production environment then you will almost certainly need to consider using Passenger (mod-rails) as well.
https://www.phusionpassenger.com/
HTH.
James B. Byrne wrote:
On Tue, November 20, 2012 06:53, C. L. Martinez wrote:
On Tue, Nov 20, 2012 at 11:23 AM, Phil Dobbin bukowskiscat@gmail.com wrote:
On 11/20/2012 08:39 AM, C. L. Martinez wrote:
Somebody knows if exists some rpm package for ruby rails??
Normally, rubygems is the way to go to install Rails.
Sure, but how can I update rubygems installed in one system??
The main problem with RHEL and Ruby on Rails is that the version of Ruby available for EL6 from reputable repositories is too old. RoR 3.2 can get by on 1.8.7 but support for Ruby versions prior to 1.9.3 is being dropped in the forthcoming RoR v4 release. Thus, a RHEL/CentOS rpm package for Rails really will not give you much, if anything.
I suggest that you investigate both RBENV and RVM as alternatives to using the rpm packaged Ruby. I advise you consider that for RoR projects the Bundler gem is the preferred way of installing and managing project specific packages, including Rails itself.
The down side to this approach is that your production servers need to have development tools installed to build the Ruby interpreter and the support gems. The up side is that you can version specific ruby vms and gemsets on a project by project basis.
https://github.com/sstephenson/rbenv https://rvm.io/ http://gembundler.com/
I used rvm almost from its inception but have recently changed to rbenv as this has a much smaller footprint on the user's environment. But both are excellent products. If you are installing RoR for a production environment then you will almost certainly need to consider using Passenger (mod-rails) as well.
Here, they use Ruby, the enterprise version - is that what you mean by RBENV or RVM? The next release of ruby? from RH? will be the 1.93 or some such, and include all the stuff in the enterprise version.
Development tools on a production box are a very, VERY bad idea. I assume you can build the ruby app on your development box, and then move it as a package to test, then prod.
I've also seen an article or two about ruby not scaling up well. From my experience here, the apps seem to be *very* fragile, and it reminds me of python 10-12 years ago, where updating it one or two subreleases broke everything that had been working, including system tools.
ObStmt: No, I don't like ruby.
mark
On Nov 20, 2012, at 8:28 AM, m.roth@5-cent.us wrote:
James B. Byrne wrote:
On Tue, November 20, 2012 06:53, C. L. Martinez wrote:
On Tue, Nov 20, 2012 at 11:23 AM, Phil Dobbin bukowskiscat@gmail.com wrote:
On 11/20/2012 08:39 AM, C. L. Martinez wrote:
Somebody knows if exists some rpm package for ruby rails??
Normally, rubygems is the way to go to install Rails.
Sure, but how can I update rubygems installed in one system??
The main problem with RHEL and Ruby on Rails is that the version of Ruby available for EL6 from reputable repositories is too old. RoR 3.2 can get by on 1.8.7 but support for Ruby versions prior to 1.9.3 is being dropped in the forthcoming RoR v4 release. Thus, a RHEL/CentOS rpm package for Rails really will not give you much, if anything.
I suggest that you investigate both RBENV and RVM as alternatives to using the rpm packaged Ruby. I advise you consider that for RoR projects the Bundler gem is the preferred way of installing and managing project specific packages, including Rails itself.
The down side to this approach is that your production servers need to have development tools installed to build the Ruby interpreter and the support gems. The up side is that you can version specific ruby vms and gemsets on a project by project basis.
https://github.com/sstephenson/rbenv https://rvm.io/ http://gembundler.com/
I used rvm almost from its inception but have recently changed to rbenv as this has a much smaller footprint on the user's environment. But both are excellent products. If you are installing RoR for a production environment then you will almost certainly need to consider using Passenger (mod-rails) as well.
Here, they use Ruby, the enterprise version - is that what you mean by RBENV or RVM? The next release of ruby? from RH? will be the 1.93 or some such, and include all the stuff in the enterprise version.
Development tools on a production box are a very, VERY bad idea. I assume you can build the ruby app on your development box, and then move it as a package to test, then prod.
I've also seen an article or two about ruby not scaling up well. From my experience here, the apps seem to be *very* fragile, and it reminds me of python 10-12 years ago, where updating it one or two subreleases broke everything that had been working, including system tools.
ObStmt: No, I don't like ruby.
---- enterprise ruby is 1.8.7 and ideal for CentOS 5.x but James is correct that rbenv or rvm will give you an amazing amount of flexibility - the ability to run different versions of ruby on a single server.
Ruby is the backbone for many configuration management systems such as puppet and chef and it scales fine. It's only fragile when deployed by people who assume knowledge they don't possess. Ruby is also used for one of the most brilliant software deployment systems (capistrano) ever.
Ruby and the various gems/frameworks that it has spawned have been changing more rapidly than an enterprise bundle such as CentOS and its' upstream counterpart could ever embrace (likewise, Ubuntu) and thus the tools like rvm, rbenv and the basic distribution tool of ruby itself, gem are really the only adequate tools which does mean having the development tools on a production box. It seems that the notion of not wanting development tools on a production box has roots in an older world where it would slow down an attacker by making it harder for him to compile software on a hacked account but seriously, that's so old school.
Craig
Craig White wrote:
On Nov 20, 2012, at 8:28 AM, m.roth@5-cent.us wrote:
James B. Byrne wrote:
On Tue, November 20, 2012 06:53, C. L. Martinez wrote:
On Tue, Nov 20, 2012 at 11:23 AM, Phil Dobbin bukowskiscat@gmail.com wrote:
On 11/20/2012 08:39 AM, C. L. Martinez wrote:
<snip>
Ruby and the various gems/frameworks that it has spawned have been changing more rapidly than an enterprise bundle such as CentOS and its' upstream counterpart could ever embrace (likewise, Ubuntu) and thus the
So, every subrelease breaks something that ran fine on the previous release? Is that what you're saying?
tools like rvm, rbenv and the basic distribution tool of ruby itself, gem are really the only adequate tools which does mean having the development tools on a production box. It seems that the notion of not wanting development tools on a production box has roots in an older world where it would slow down an attacker by making it harder for him to compile software on a hacked account but seriously, that's so old school.
"So old school". Yep. And it's so much more secure, and bullet proof to be hit by crackers and script kiddies?
I don't think so.
mark
-
Craig White -
James B. Byrne -
m.roth＠5-cent.us