[DRE-maint] Bug#462027: ITP: libactiverecord-ruby -- library that ties database tables to classes in Ruby

[Gunnar Wolf]

Adam Majer dijo [Thu, Jan 24, 2008 at 01:36:47AM -0600]:
> Rails is not just railties, but specific dependencies on specific
> versions of activerecord, actionpack, activemodel, actionmailer and now
> the activeresource (actionwebservice doesn't exist in new rails). This
> is kind of similar to what happens with plone and its dependencies. If
> you try using versions that are not from the same rails version, you are
> asking for trouble.
> 
> The real problem is the debian's packaging environment which cannot
> handle more than one version of a package installed at the same time.
> This problem doesn't really exist with ruby gems, but that is geared
> towards ruby only. So, packaging rails separately from activerecord
> makes sense in the ruby gem world, but it makes less sense in the Debian
> world. Essentially in Debian you end up with the same stuff installed if
> you want to use rails. If you just want to use activerecord, you have to
> install rails which gives you minimal disc overhead over "mutli-package
> solution".

Umh... I follow you. However, it might be hard for a user to find
where Active Record is (i.e. by looking for it under the lib.*-ruby
packages). Or they might just not want the whole Rails setup
installed. But yes, I understand the integration problems this poses.

How would you feel then about having an _independent_ Active Record
package, not tracked in any way by Rails (i.e. Rails would still
provide Active Record by itself). And add to Rails Provides: libactiverecord-ruby
and Conflicts: libactiverecord-ruby. This could be done for the
different railties parts, of course, even if they are not (yet)
provided as separate modules by Debian. 

As a parallel - In the pkg-perl team, we have some packages which are
part of perl-modules (that is, part of the standard library). We don't
even conflict there, of course - we just provide fresher versions that
are required. And, as in the Perl file hierarchy the vendor-provided
modules are before the core (of course, local user-installed modules
go even higher up). This could be another way to solve it: Have Rails
provide the modules, _don't_ conflict with the independent packages,
but (somehow - sorry, I'm still a newcomer for this) tweak the Ruby
include path to go to the Rails directory first if running under
Rails, or have it last if not. Sounds feasible?

> The only solution I can see that doesn't result in meaningless extra
> packages is for rails to install the active_record and other libs under
> /usr/lib/ruby/1.8 and then use a bunch of symlinks to recreate the
> structure as used by rails. This would allow one to use active_record by
> just
>    require 'active_record'
> instead of including the current rails path in the application. What do
> you guys think?

Yes, this would certainly be welcome. ActiveRecord by itself is enough
justification... And there are many other projects which use other
parts of Rails, although not Rails itself (i.e. I'm thinking about
Pentabarf, which we currently use for organizing Debconf).

> Splitting the package into separate packages where rails would depend on
> all of them seems a little meaningless to me. It would only result in
> token disk space savings to select few people that only use
> active_record and not rails. And if you can't spare 2M of disk space,
> well, ruby may not be the best choice for the environment anyway.

Well, but OTOH you could say the same about a great deal of
Debian. And I do value being able to install some Gnome or KDE
applications without bringing them all in!

> PS. For an example why splitting rails would not be a good idea see old
> zope-cmfplone in Etch, and new zope-plone3. Look at the dependencies.
> The package is A LOT cleaner now though it is about 10x the size. The
> old way of packaging it caused all sorts of grief.

Agree. But middle ground might be reachable!

-- 
Gunnar Wolf - gwolf at gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF