Antonio Terceiro wrote: > Bob Proulx escreveu isso aí: > > What is the best way to deploy Rails on Debian? > > ... > > Advice? What is the Best Practice for Rails on Debian? > > All the javascript stuff did not get into wheezy because they depend on > NodeJS, so right now the Rails 3 stack will not complete in pure wheezy: > in special, since ruby-coffee-rails and ruby-uglifier did not migrate, > the Rails 3 asset pipeline is not available. Thanks for the summary. It helps me understand the situation. > My main goal when pushing to get rails3 into wheezy was to be able to > upgrade Noosfero (http://noosfero.org/) to rails3, and since it does not > use the asset pipeline that will be no problem for me personally. Makes sense. > *But* I also plan to support the use case for new applications, so my > plan is the following: Excellent! > - get the missing pieces into wheezy backports as soon as possible, so > that users that install rails3 using wheezy+wheezy-backports can have > a smooth experience, with the asset pipeline and everything (which is > BTW a very cool platform for managing CSS/Javascript code in Rails > apps). Before you mentioned this I was thinking that it would good and nice if ruby and rails had an out-of-band repository for getting updated packages out similar to the way http://mozilla.debian.net/ operates for firefox. Because the upstream is very rapidly changing and that is too volatile for a stable release. Having some layer of stability between the rapidly changing upstream and users production servers would be most beneficial. But it isn't directly compatible with the rules for Debian's Stable and we are past freeze making the task of trying to polish this up for release difficult. I could see a repository http://ruby.debian.net/ or http://rails.debian.net/ to hold those types of packages. And then here you suggest using wheezy-backports for that purpose. I think that would be a good match. Yes. Please! :-) > - maybe patch railties to comment out the asset pipeline part in the > Gemfile created for fresh applications if those packages are not > available, so that `rails new foo` in pure wheezy does not fail > miserably like that. Any opinions on that? I think doing _something_ to address that would be helpful to users who are following canned recipes and trying to learn. They generate a lot of the questions and the responses to those questions often generate the most emotion. I think if we can help the user along in those cases it will reduce the questions which will reduce the emotional responses to those questions. I am talking about all of the flames usually occuring on the upstream mailing lists around downstream packaging. I am about 50% for removing the default addition of those gems to the gemfile. They are not always needed. If a user wants them then adding them is easy. Except that is a modification to the standard upstream recipe to remove a default setting that others will not like to see removed. I think that might be received poorly. I am about 50% for adding a helpful comment that suggests to them that they install those gems from backports. (Assuming that backports will be updated to contain them as you suggest.) Except the message isn't in a convenient place to intercept and patch. IIUC bundler is simply producing a generic complaint about not being able to find a listed gem from the Gemfile. Is there a method to encourage those gems to be installed from backports such that the new learner following recipes will be helped along the path without too much trouble? Bob
Attachment:
signature.asc
Description: Digital signature