Thank you for the feedback, Amanda and Brian. Requesting more comments: Do other webstackers have thoughts what the best option for Rails is?
Thanks, -ps Brandorr wrote: > On Thu, Feb 21, 2008 at 6:51 AM, Amanda Waite <Amanda.Waite at sun.com> wrote: > >> Prashant Srinivasan wrote: >> > Jyri, these are good points, and this(integrating Rails into Solaris) is >> > a problem with no solution that satisfies all packaging mechanisms/our >> > goals. >> > >> > What we wanted to(and still do) achieve when we set out on this effort >> > was to package Rails + dependencies to present the end user with a >> > pre-configured set of components for Rails + dependencies + some >> > critical components like db connectivity. Installing these components >> > manually doesn't present a difficult proposition to the end user(ie., >> > utterances of "gem install rails", "gem install mysql >> > --with-mysql-dir=/usr/mysql/5.0", and/or "gem install postgres"), on the >> > other hand, if your target is a Ruby end user, [s]he is probably going >> > to have to do this anyway, so why not save them the trouble? >> > >> > Given that rubygems support in Solaris is already present, we have three >> > options to support Rails(and other gems). >> > >> > (1) Use Solaris packaging exclusively(ie., gems not allowed). >> > (2) Get Solaris and Rubygems to co-exist. >> > (3) Use Rubygems exclusively. ie., don't bundle Rails. >> > >> I'm a supporter of option 3), I feel that we'll just tie ourselves in >> knots if we do 2) and 1) is just not going to fly with anyone who's used >> Rails before. >> But having said that, an idea would be to have a Solaris package that's >> built around Gem management, where the package installer uses the Gem >> command to check for an existing installation of the Gems that the >> packages bundle, then displays what's installed currently and offers the >> user the choice to do nothing or to install the Gems. In that case the >> Solaris package would just be a wrapper package (i.e. Rails Support) and >> not actually package any files. The package itself could setup a local >> (and temporary) Gem repository. >> >> It sounds complicated and probably impossible given the packaging >> restrictions we have. But it's no more complicated than option 2) would >> be with it's countless scenarios. >> >> >> >> I see in debian rake is delivered separately. Is it desirable to >> >> require installation of rails for someone who only needs rake (if >> >> that's a reasonably common use case)? >> >> >> >> >> > >> > We can easily package this separately if it's felt that non-Rails >> > applications commonly use Rake too. >> > >> Rake download stats are hopelessly skewed by it's attachment to Rails. >> It isn't rev'd as often as the other Rails dependencies and so isn't >> downloaded as frequently, but it's difficult to determine how often it's >> downloaded independently of Rails. Rake is a very useful tool, and my >> instinct is to agree that we should package it separately. >> > > I am in favor of gems for everything, with no OS level packaging at > this point. The reasons I believe this are: > 1) Ruby and Ruby on Rails are evolving too rapidly to keep up. (It > will be a constant game of catch up.) > 2) Gems have pretty much become the defacto way of managing > extensions. So much so in fact that ruby-gems will be merged with ruby > soon. (v1.9) > 3) If we were to use OS packaging, we have the choice of using > non-standard paths, or putting ourselves at risk for inconsistent > package metadata. (If os packages are just bundling gems). Depending > on how people go about installing gems and os packages. > 4) Gems supports having a choice of installing various extension > versions. (Or even multiple versions) This is an important feature, as > interface stability is still not the highest priority among extension > developers, so having the choice to run tested and potentially older > versions is still very needed. OS packaging might have a difficulty > with this, as typically the only choice is to install the latest > package. > > Note: > 1) Running "gem install Rake" isn't a big deal. I'd say if someone is > going to be running ruby, known how to use rake, it is extremely > unlikely they won't know how to install rake. > > Cheers, > Brian > > >> Amanda >> >> >> _______________________________________________ >> >> >> webstack-discuss mailing list >> webstack-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss >> >> > > > >
