From: Austin Ziegler Date: 2005-09-30T23:02:46+09:00 Subject: 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 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 * halostatue@gmail.com * Alternate: austin@halostatue.ca