Re: Bug#293055: Progress with rails?
On Mon, Feb 07, 2005 at 06:11:51PM +0000, Adam Majer wrote:
> It is not a gem that will be packaged. I got upstream source (from
> tagged subversion - there doesn't seem to be access to actual source
> otherwise), change a few things, like remove dependency on gems and
> subversion stuff, and make a deb out of it.
*That* is the point I can't get thru, by the look of it :-)
Rails upstream is a gem (but there's a tar.gz). I'm not actually
*that* concerned about rails, since most people using it do not seem to
care about Ruby, or for that matter, programming. My concern wrt to
gems in general is that code that reads like this:
require 'rubygems'
require_gem 'mygem'
in a "Debianized gem", like the one you propose, becomes:
require 'mymodule'
That's what I meant by 'not source level compatible'. Yes, I know
about this:
begin
require 'foo'
rescue LoadError
require 'rubygems'
require_gem 'bar', '>= 1'
end
Even if this code is very Ruby-like, _it_ _is_ _not_ what the
(rubygems) documentation says you should do.
That is my concern with packaging a gem as a "non gem".
Even more, rails bundles a number of other modules (e.g. the Ruby port
of Gábor Egressy's Text::Format; TMail), which I'm sure are useful by
themselves.
I actually wonder if actionmailer, actionpack and activerecord are
useful by themselves. Active Record in particular looks rather
interesting, very much like Class::DBI.
> Rails doesn't need gems for use.
I had the impression that rake does require rubygems. Isn't that the
case?
> Making ruby gems work on Debian is simply changing gems to install
> things in such a way that they will not interfere with Debian.
I'm not sure what you mean.
> I don't think gems are a Debian package yet.
There's <41FA4661.4030804@debian.org> and
<41FDAAA4.70502@sgtpepper.net>. I haven't had the time to take a look
at Akira's dh_rubygems.rb (Arika, could you please drop the ".rb"
bit?). That might as well address my concenrs.
> But if and when they are, installed packages with gems should
> probably end up in /usr/local prefix since gems are 3rd party and not
> from Debian.
Which kind of ends up in the same trouble as CPAN modules and Debian:
CPAN upgrades a module because there's a Debian package installed but
it's an older version, and when the Debian packages get upgraded, the
change doesn't reflect on the system because the local path has
precedence over the path that the Debian package uses, like this:
$ perl -le 'print join("\n", @INC)'
/etc/perl
/usr/local/lib/perl/5.8.4
/usr/local/share/perl/5.8.4
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl
.
$ ruby -le 'print $:.join("\n")'
/usr/local/lib/site_ruby/1.8
/usr/local/lib/site_ruby/1.8/i386-linux
/usr/local/lib/site_ruby
/usr/lib/ruby/1.8
/usr/lib/ruby/1.8/i386-linux
.
--
Marcelo
Reply to: