[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Rails on Debian?

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:


> - 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?


Attachment: signature.asc
Description: Digital signature

Reply to: