Re: gems is a language change, not a pkging system (Re: Require Namepaces and RubyGems' effect on LoadPath problem)

On 9/30/05, Sean E. Russell <[e-mail]> wrote:
> On Wednesday 28 September 2005 08:43, Austin Ziegler wrote:
>>> I don't understand the comment about "those ... who have to deal
>>> with other platforms".  What does that mean?  From the packager's
>>> point of view?  From the library author's point of view?
>> I develop software at work that runs on RedHat 7, 8, 9, SuSE 9.x,
>> FreeBSD, WinNT, Win2000, WinXP, Win2003, iSeries, NetWare, HP-UX 11,
>> AIX 4.3.3 and 5.x, and Solaris 7, 8, and 9. Do you *seriously* think
>> that I'm going to care about Debian's little packaging system at this
>> point?
> No, I don't expect you to care about Debian. Luckily, Ruby is
> developed with a broader audience in mind.

Hmm. I don't care about Debian in the sense that I do not believe that
Ruby or its packaging system should *cater* to Debian and forget the
rest of these platforms. There have been statements from some of the
Debian packagers which have been, IMO, "cater to me or else." I have to
worry about a lot of platforms with a lot of different -- and
incompatible -- packaging systems. For our commercial product, we've
punted. We *don't* package natively; we have a .tar.gz with an install
script that's pretty good about figuring out what it needs to do.

>>> Personally, I don't think software installation is at all the job of
>>> the language. Software management is the job of the operating system
>> Spoken like someone who gets to use a single platform that actually
>> has a package management system. I respect your work, Sean, but it's
>> the developer who gets blamed when an installation fails, even if the
>> developer didn't package it. I'd much rather package it and get
>> blamed appropriately.
> Yes, I know the developer takes a lot of grief.  My point was that
> gems is simply Yet Another package manager for Joe User to try to
> remember, on top of yum (or apt-get, or emerge, or whatever), "perl
> -MCPAN", and whatever other languages applications he's trying to use
> are developed in.

Mmm. Again, I don't believe that it has to be. I really see no problem
with "wrapping" gems in .deb or emerge or rpm or whatever. It might not
fit the particular packaging philosophy of a platform, but at that
point, the end user doesn't even know that they're using RubyGems. And
they don't *have* to know, either.

> I see parallels in this argument with the arguments between native
> GUIs vs. platform independant GUIs. Users -- *users* mind you, not
> developers -- want a UI that looks most like what they're used to.

Agreed.

> They complain vociferously about applications that don't. My argument
> is that package management is the same issue; worse because a special
> tool for managing libraries actually breaks native library management
> (for platforms that have it), and better because users only rarely
> have to deal with it.

See, I don't buy the ultimate premise (that RubyGems *breaks* native
library management). Never have. I will agree that it's a conceptual
mismatch and that there are things that can be done to minimize that
conceptual mismatch, but that doesn't change that it doesn't actively
*break* things.

[...]

>>> Incidentally, last time I checked, Gems *still* didn't work behind
>>> an authenticating firewall, despite the fact that I can get through
>>> with
>> Just a simple question -- how would one authenticate with such a
>> firewall with Ruby in general?
> Does it matter, if it means that I can't install libraries with Gem
> *but* I can still install packages with Gentoo's emerge? Both work
> over the network. If I can get a tarball for a Ruby library that
> requires me to run setup.rb, I can still install my library. If all I
> have access to is the Gem, I'm screwed.

Hmm. You *can* install gems locally. That said, my question was more
pragmatic, and has been answered otherwise -- the CVS HEAD version of
RubyGems has an experimental authenticating proxy patch.

>>> That's fine. However, I agree with Sam that versioning should
>>> handled separately from the language-specific package manager. The
>>> manager is
>> Again, I disagree, and I think that it's one of the more elegant
>> things that RubyGems has done. The *reality* is that software
>> applications are
> This may be true. RubyGems may have an elegant versioning mechanism.
> Is it not possible to refactor it out of RubyGems and make it a
> stand-alone package upon which RubyGems requires?

I do not believe so, as RubyGems solution to this is a side-effect of
the packaging concept (1-gem-1-dir, which I've suggested to be expanded
to 1-gem-1-dir-pattern applied against multiple prefixes). It is like
stow without the sitelib installation. I do not believe that anything
that tries to depend on stuff that may be installed in site_ruby will
work.

[...]

>> heavily dependent on version matches. Anything else is DLL hell. I
>> can't express how much I *hate* Linux, libc, and libstdc++ nonsense
>> and soversions. There's an incompatible break between 3.2.5 and 3.2.6
>> of libstdc++ (I think those are the right versions) -- it was a
>> fscking *nightmare* for us last year.
> Yeah, we don't disagree here. I think you misunderstand me: I *like*
> versioned libraries. I think Ruby needs a good solution. I simply do
> *not* believe that it should be tied so heavily to a package manager.

How would you solve the versioned libraries problem in Ruby, then?

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