Re: Bug#293055: Progress with rails?
On Tue, Feb 08, 2005 at 10:46:30AM +0100, Paul van Tilburg wrote:
> > 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'.
>
> That is IMO the whole (and maybe not the only) gem problem. It is
> meant as means of easy distribution and packaging but the source is
> changed for it.
Yes, in the meantime I have come to understand that much. Someone
pointed out to me that rubygems is part of that "one-click ruby"
installer thing for Microsoft Windows and that's one of the reasons why
it's so popular.
The more I look at it the less I like it. Gems is very non-Unix. One
program per directory is a Windows concept and *does* cause trouble in
the long run (actually because bloggers suddenly got bit by the rails
bug and therefore need to install ruby).
> RPA (http://rpa-base.rubyforge.org/wiki/wiki.cgi)
Oooh... nice! Really nice!
I think this is something really worth supporting.
It'd be spiffy to get RPA to be aware of the Debian packages installed
on the system (say, there's a rake package, therefore I don't need to
install the rake RPA). It could be done by means of mappings provided
by the packages themselves ("I'm the package also known as Foo RPA",
e.g. "libsqlite3-ruby is sqlite3-ruby"). A dh_ruby could easily take
care of this.
rpa to deb is probably doable without much trouble. The bad point
about rpa is that it needs to lock the database for building an rpa, I
didn't quite get why.
> experienced the same problems packaging rails, but they've split the
> whole thing up and Rails and it's elements (active*) are seperately
> installable.
Yes, they've done a fine job, too. active* are easy. railties is...
ugh, not so nice.
> You live either in the Gem world or you do not?
Yes, that's the trouble. I rather not.
> > > 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.
>
> Why?
I haven't had the chance to check if there's some magic in there that
"peels the egg". On second thought I don't think there is, looking at
some actual code it would be rather hard to do this.
> I think this raises a problem among all larger scripting languages.
> They all have a distribution system with a lot of libraries and
> programs in it. Not all can be in Debian, so people might install a
> system like CPAN, RPA, Gems to get libraries that Debian misses
> thereby superseding Debian's work. That is a users choice but he
> might not know what he is doing. I'm still thinking what to do about
> it in RPA.
Sure.
CPAN get this "almost right", because it checks if the required stuff
in to be found on the system. Gems and RPA get this wrong: they want
"their" version to be installed. I see a better chance of making RPA
Debian-friendly than Gems.
The other bad point of RPA is that it doesn't seem have a way to say "I
need foo > 2". Perhaps I only missed it.
Marcelo
Reply to: