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

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.

I only care about Debian for egalitarian reasons; I don't use it myself.

"First they came for the communists, I did not speak out because I was not a 
communist. When they came for the social democrats, I did not speak out
 because I was not a social democrat. When they came for the trade unionists
 I did not speak out because I was not a trade unionist. When they came for 
the Jews I did not speak out because I was not a Jew; And when they came for 
me, there was no one left to speak out."  (Martin Niemler)

> > 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.

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.  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.

I appreciate your point of view on this, and I understand the problem you're 
trying to solve.  For the record, the approach you're advocating worked well 
for Excel.  They wrote their own C compiler for Excel because they don't 
trust outside dependencies -- their motto is, in fact, "find all 
dependencies, and eliminate them".  Consequently, Excel is one of the most 
robust and reliable Microsoft applications.  However, I still believe that, 
in this case, CPAN-like solutions are more of a curse than a cure.

> > 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.

> > 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 can't use RubyGems' elegant solution if I choose not to use RubyGems, and 
yet I may still want such a solution.  This, to me, is proof of poor 
coupling.

> 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.

-- 
--- SER

"As democracy is perfected, the office of president represents, 
more and more closely, the inner soul of the people.  On some 
great and glorious day the plain folks of the land will reach 
their heart's desire at last and the White House will be adorned 
by a downright moron."        -  H.L. Mencken (1880 - 1956)