Re: Rails on Debian?
On 09/09/12 20:15, Antonio Terceiro wrote:
<snip>
The massive amount of work that was put by the Ruby team during the
Wheezy cycle was in part to reduce the need to think of "the Ruby
ecosystem" _versus_ "the Debian ecosystem".
The impedance mismatch has been hugely reduced from a technical
perspective, thankfully, but there's still the difference in viewpoints.
Debian comes with the concept of a "stable version". This is almost
entirely absent from rubygem projects, and where it does exist it almost
universally doesn't match Debian's definition, and even if it did match
perfectly there'd still be the calendar differences to mess things up.
That's not something that any amount of tooling can smooth over.
Of course, the fraction of
useful Ruby packages that are packaged in Debian is very small, so
applications that depend on non-packaged stuff might be easier to manage
with Rubygems. But in the end, the code of an application should not
need to care how its dependencies were installed on the system.
This is true. In the past I've shied away from mixing and matching
packaged and unpackaged gems, but the situation looks healthier now.
I'm sure you have further criteria for when you'd pick `apt-get
install rails` over `gem install rails`, and it would be good to
hear them - especially ones that'll hold 18 months from now. I'm
not being snarky here, when people ask me about this I have no
better advice to give them than what I've written above.
In the case of Noosfero, my main reason for sticking with Debian
packages is being able to manage not only Ruby dependencies, but also
non-Ruby ones, like apache, varnish, memcached, PostgreSQL, etc, etc,
using a single mechanism.
So are *all* the ruby dependencies for Noosfero available as Debian
packages in Wheezy, or do you run a local apt repository to fill in the
gaps? That's an approach I could certainly appreciate, but if that *is*
the recommended approach then it could possibly use a write-up :-)
I'm also interested in how you square this with development using
bundler, which doesn't respect system-provided gems. Is there any way
at the moment to go from `bundle package` to having a Wheezy-compatible
apt repository that doesn't clash with Wheezy-provided gems? For those
of us not (yet) developing on Wheezy, this is a particularly relevant point.
In the end, this issue boils down to the old debate of whether you
should rely on system packages or if you should do it yourself (or rely
on third-party automation scripts etc). Both approaches have advantages
and drawbacks, which I won't rehash here.
I think it's inevitable in any interestingly-sized project that there
will be dependencies which *can't* come from system-provided packages,
and it's handling that boundary which is confusing.
Another important point for me is targetting a known-stable base system,
with well-known versions of all the components (i.e. Debian stable, or
Ubuntu LTS, or ...), versus having to worry about incompatibilities
between different versions of each of them.
That's a persuasive argument, but it does inevitably lead to problems
where a non-packaged dependency becomes incompatible over time and
security patches (or just bug fixes) stop coming to the last version you
can use.
--
Alex
Reply to: