Note: I removed the specific reference to ruby 2.3.0. The Gemfile now requires >= 2.0.0, and the cgi assumes that ruby is on the PATH.
On 17 March 2016 at 15:19, sebb <seb...@gmail.com> wrote: > On 17 March 2016 at 13:18, Sam Ruby <ru...@intertwingly.net> wrote: >> On Thu, Mar 17, 2016 at 7:20 AM, sebb <seb...@gmail.com> wrote: >>> As the subject says. >> >> Depends on your definition of require. Ruby >= 2.2.0 will use less >> memory and be more responsive due to improvements in garbage >> collection: >> >> https://www.ruby-lang.org/en/news/2014/12/25/ruby-2-2-0-released/ >> >> For that reason, I'd like the deployed code to use a version of Ruby >> that has the improved GC. > > Fair enough, but that can be done in the documentation and/or puppet config. > No need to embed it in scripts. > >> I would agree that that shouldn't be required for development/testing. >> >> I haven't investigated, but perhaps that could be expressed in >> Gemfiles using the group construct? >> >> http://yehudakatz.com/2010/05/09/the-how-and-why-of-bundler-groups/ > > Probably, but that adds complication and does not seem necessary here. > > Note that as it stands, AFAICT the status passenger code won't even > run with 2.3.1. > > The same restriction would presumably apply when using the ruby > statement as part of a group, since it's the statement itself that > does not support version ranges. > >> - Sam Ruby >> >>> MacOS/X comes with 2.0.0 which seems to work for most if not all the code. >>> >>> So is it necessary to specify ruby 2.3.0 in status/Gemfile >>> and /usr/local/bin/ruby2.3.0 in passenger.cgi? >>> >>> In particular it seems wrong to specify that ruby is under >>> /usr/local/bin, even if 2.3.0 is required. >>> >>> I see that Gemfile does not support ruby version ranges (Why??), but >>> one can use the following work-round: >>> >>> raise 'Ruby version must be at least 2.0' unless RUBY_VERSION.to_f >= 2.0
