Re: gems is a language change, not a pkging system

On 9/28/05, Ralph Amissah <[e-mail]> wrote:
[...]
>> Sorry, but the idea -- that is, RubyGems -- works. The problem -- a
>> Ruby packaging system -- exists. Do you see a solution other than
>> RubyGems being available? I sure as hell don't, and that's the
>> problem, Ralph.
> You have no solution, I have no problem (or seldom do).

You may not have a problem, but anyone working on older versions of
RedHat, Slackware, Windows, OS X, HP-UX, AIX, and I'm sure a few other
operating systems (and, by the way, I have to *support* applications on
most of those platforms) does. It's that simple. When the scope of the
problem extends beyond the nose of Debian's comparably tiny little
territory, it's quite unsurprising that I really don't care about
individual platforms packaging systems and far prefer the cross-platform
language-specific solutions.

> The solution suggested is not equal to, and cannot be, to what i
> currently have. [...]

Nor does it try to be. It doesn't try to solve external dependencies. It
tries to solve *Ruby* problems. This might be a condition where better
error messages for missing external dependencies might be useful -- but
that's not always easy.

>>> Work that out, then offer us Gems "in ruby head" Whatever you come
>>> up with must play WELL with existing packaging systems.
>> I frankly don't care if it plays well. I never have, I never will.
> I do care... this is one of the reason i looked round and settled for
> using Debian. They do care about packaging.

I wish I believed that. They care about *their* packaging. They don't
actually give a damn about other platforms. Their variation on the old
Scottish saw is "if it ain't Debian, it's crap!" Well, sorry, but I live
in the real world. And they tend to not like solutions that don't fit
their narrow preconceptions of "right," even if there are definite
advantages to those other solutions.

> [...] oh and did i say, they don't rush into things either, by rush,
> and the definition of rush traditionally has not been time based, but
> getting things right.

Unfortunately, they also don't rush to help out when they fear things
might be wrong for their platform even if they are right for others.

> Others must care as well, there are other decent native packaging
> systems out there.

Some do. Some have even given guarded approval of the direction that
RubyGems could take. There's other packaging systems there -- and some
of them are far more pragmatic than the Debian approach, apparently. But
you know what? I don't *need* a native packaging system because I don't
develop Ruby software for native platforms. I develop Ruby software for
Ruby platforms. That's the solution I need.

> That said a language packaging system must play well with existing
> native packaging systems, it cannot replace them, (especially not for
> general users).

RubyGems can play well with existing packaging systems *already*. The
FreeBSD solution indicates that. However, there are things that can be
done to improve the integration -- and I believe the proposals that I've
made can do that. But you know what? The RubyGems developers aren't
going to care much about implementing anything to help unless there's
commitment to actually *use* these or other proposals. Their focus is --
and must be -- Ruby packaging systems, not native packaging systems.

> It plays well at the very least if not able to help, by making sure it
> does not hinder, making sure it gets and stays out of their way.
> (Given that it is being designed from the ground up for Ruby, it
> should take into account these interests and be designed also to
> help).

You know ... you said you haven't used RubyGems. I suggest trying it,
recognising that the current implementation is a hack (an elegant hack,
nonetheless) on top of the current loading.

> My only concern is this. Get it (Gems whatever) right before anything
> goes in. Given the fact that these concerns were expressed at the
> outset, and still have not been fully met... well, fix them first,
> then consider. There is no rush. Not getting this right would be a
> flaw that depreciates the value of Ruby. There is no hurry.

It *is* right. And these concerns have been expressed at the outset, but
no solutions compatible with the RubyGems philosophies have been
presented.

> OK if:
>
> (a) Gems helps native packagers (ok i am told this is not its'
> purpose)

This shouldn't be a goal. It may be a side effect. There is, IMO, an
open question on how RubyGems would support dual-architecture systems.
The proposals that I've made -- and I really do suggest you look them up
if you care -- will definitely help with the dual-architecture system,
but I *believe* that Ruby will already support this even in a non-FHS
compliant way.

[...]

> I don't think gems can seamlessly install Rails and its appendages
> (mysql etc.)

It shouldn't install OS dependencies. It doesn't try to. It *might* be
possible to detect that these dependencies are missing -- but I'm not
even sure that this is something that's important or necessary.

> I don't think gems can seamlessly install SiSU for me, and integrate
> its parts on my system.

I donno. I haven't looked at SiSU. But if SiSU is mostly Ruby, or even
Ruby with a bit of compiled code, you could probably do it.

>> Has anyone seen fit to develop a viable alternative to RubyGems? The
>> rpa-base effort floundered. So, where's the alternative, Ralph?
>>
>> Coming out at this late date -- and without an alternative -- is just
>> sour grapes.
> Sour grapes sounds a disingenuous characterization of genuine existing
> concerns.

It's not disingenuous. If the problems have been well known for all this
time, why haven't people been *continuously* working with the RubyGems
team to solve these problems ... or, if the RubyGems team has been
nonresponsive, creating a viable alternative solution?

> rpa sought to communicate these needs, and to work with Gems, despite
> reservations, and went out of their way not to compete with Gems, and
> even contributed substantial amounts of code to Gems.

I'm sorry, Ralph, but this characterisation of the history is distorted.
RPA -- as represented primarily by Mauricio -- did seek to commmunicate
those needs, but for one reason or another did not communicate the needs
well. Part of the problem, I think, is what I've discovered in further
discussions with him. He is extensively opposed to any solution that
does not end up installing into site_ruby; I am, in fact, opposed to any
solution that requires installation into site_ruby because of the high
probability for failure during part of the install or uninstall process.
I am equally opposed to such solutions because I think that they lose
one of the side-effects of RubyGems that has become a really powerful
feature -- multiply installed non-conflicting versions.

"Substantial amounts" is also a mischaracterization, as while the
packaging code is significant and useful, I'm not sure that it's *that*
important overall.

rpa-base was abandoned. Not from a lack of interest in the community,
but because of reasons that I frankly can't discern. Mauricio
effectively disappeared from the Ruby community for several months --
and in that time, RubyGems became accepted universally. I also believe
that Mauricio shot RPA/rpa-base in the foot by not opening up the
packaging to upstream developers, meaning that he was the packaging
bottleneck. He did some good work in that packaging -- finding and
communicating some bugs back to me -- but that ends up not serving the
developer community that well.

> from what i am reading at this time, it seems rpa should instead have
> produced a Gems replacement (not rpa that was something different, and
> it would appear a considerably more difficult task).

It's not a considerably more difficult task. It's just not been done.

> I don't speak for rpa, i do frequent the irc channel because there has
> been a lot to be learnt about packaging from people there; and i have
> been help on occasion by good folk there.

I can honestly say that I've been on good terms with both the RPA and
the RubyGems teams and that I was pushing both systems for a DATADIR
solution when I was trying to package Ruwiki last year, because I had a
problem that no package before really had that demanded a DATADIR
solution. When it came time to package PDF::Writer 1.0, RPA (and
rpa-base) were nowhere to be found.

[...]

>> I personally *would not* choose a pure Debian system for installation
>> on any of my systems. A Debian-based system that pragmatically solves
>> the philosophical nonsense behind Debian, perhaps. But not Debian
>> itself.
> Debian is wonderful technically.

Actually, I've found the philosophy of Debian getting in the way of
technology. This latest discussion -- where some Debian folks have
spoken about RubyGems without the first bit of knowledge about RubyGems
and haven't actually offered any practical solutions or alternative
implementations -- amply demonstrates that, I think.

Debian is worth paying attention to, but I believe that it is mostly as
a negative example. "This, folks, is what *not* to do."

> If your problem is with Debian philosophy, note only that is similar
> in a number of ways to that from which Ruby is derived, i am thinking
> mostly of licenses here. Perhaps you are talking about arrogance again
> here, i wonder.

Um. Actually, regarding licence, the Debian philosophy is far more
restrictive -- it favours the GNU GPL to an unhealthy degree. (I won't
get into it here, but I *really* dislike the GNU GPL. It's become a
religion for people, though, and I'm skewering their sacred cow.)

[...]

> On a related note it is hardly surprising that Debian packagers show
> interest in what Ruby proposes to come up with for packaging system,
> they are more interested and know more about packaging/packaging
> systems and packaging policy, than most, and have always looked
> towards the long term scalability and stability of their systems, even
> when things have not worked perfectly they have looked towards such
> ends.

I wish that I could believe that, again. They're finally expressing
interest now -- after having not said anything for at least a year, when
it's been very clear that RubyGems would be seeking entrance into Ruby's
core. That's just too damned late to start throwing up roadblocks. I
repeat what I said about being myopic -- they're not caring about other
packaging systems (or other operating systems without). They're caring
about themselves only.

I can also only point to the unholy mess that Ruby itself was in on
Debian, subdivided to the point of uselessness. It still is, to some
degree, but at least it's usable from the default packages now.

> We should listen more to them. It is fairly easy to see why it
> works so much better, than other packaged stuff out there.

Does it? I've never had a good experience with pure Debian. Prebuilt
live CDs (Knoppix) seem to be okay, and pragmatic offshoots like Ubuntu
seem to be okay, but Debian itself is, well, unstable at best in my
experience. Or it's a dinosaur. There's no in between for Debian.

>> Matz committed in late 2004 to early 2005 to putting a packaging
>> system in the core. He very clearly stated that this was not
>> necessarily RubyGems. In this time, no one has seen fit to create an
>> alternative to RubyGems. Now that it's time to integrate a
>> *successful* packaging system into the core, we've got the peanut
>> gallery crawling out of the woodwork saying "it's a bad idea!" Do
>> they offer an alternative? No.
> This one surprises me though, i would have thought that Matz would
> seek to ensure that a ruby packaging system that worked well with
> other packaging systems... (and thought he might even have said as
> much quite early in Gems development?). I thought Gems would have been
> engineered with such a view in mind, whatever else they do, what could
> Gems, or i be thinking? Why are we still talking about it now.

1. Gems has *never* been engineered with a repackaging view in mind. The
   reality is that a Ruby solution to a Ruby problem was needed.
   Appropriate changes that don't change the basic functionality of
   RubyGems (which now includes versioning) would have been accepted, I
   think. I think that it's fair to say that the people behind RubyGems
   are as much in the real world as I am -- they have to use and support
   a variety of different platforms, not just the little corner of the
   operating system world known as Debian. (I'm picking on Debian here
   because I think that it's the worst offender here. The trick is that
   the RubyGems effort can't cater to the balkanized packaging
   environments individually, and that any packaging solution that did
   so would be completely unacceptable.)

2. My point about the timeframe is still relevant. There's been more
   than a year to deal with this in one way (patching Gems) or another
   (an alternative system). NEITHER has been done.

>>> It is unlikely i will engage further in this debate, but i am sick
>>> of seeing this shoved as some wonderful solution, and a done deal,
>>> if it fails as obviously as you and others state it does, in what
>>> should be one of its more obvious and primary objectives (in
>>> addition to whatever else it might do for you).
>> Sorry, but it has never been an obvious or primary objective that
>> RubyGems should help people who want to integrate with native
>> packaging systems in ways that are in and of themselves not
>> compatible with RubyGems philosophy. The RubyGems developers that I
>> have spoken with have suggested that solving the Ruby packaging
>> problem has been the most important thing, and everything else is
>> secondary.
> I don't see how anything about ruby packaging can be considered
> *solved* if it is proposed for ruby core and has failed to take into
> account this aspect that has been presented as a concern from close to
> its inception.

"Presented as a concern." Where's the patches, Ralph? If that's been
done, where's the alternative implementation to give Matz a choice?

Gems *is* right. Gems will be *better* if certain steps are taken when
integrating it into the core. As I've said, I *am* in discussions with
various people about what I think might work and how to approach some of
it. But raising this *now* is, itself, disingenuous -- if you don't have
a concrete solution to offer in its stead.

Ruby needs a packaging system more than it needs to work cleanly with
Debian.

-austin
--
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]