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

On 9/28/05, Sean E. Russell <[e-mail]> wrote:
> On Monday 26 September 2005 21:29, Austin Ziegler wrote:
>> Then you fail to see the point in general. Ruby needs something that
>> works similar to -- but better than -- CPAN. This means a packaging
>> system. You may not see it, but those of us who have to deal with
>> other platforms see it.
> Well, I'll agree there.  CPAN is an anti-solution which causes more
> problems than it solves.  Only people who work with Perl regularly
> seem to like it; for users of Perl applications, it is often more of a
> curse.  There are even many Perl developers who grumble about CPAN.
> However, Perl is stuck with CPAN.  It is so intrinsically intertwined
> with Perl that getting rid of or replacing CPAN would be an excercise
> in pain and suffering the likes of which hasn't been seen since...
> well, pick your favorite historical ethnic atrocity.  However, at
> least CPAN isn't built into Perl.

Hmmm. I donno. I think that it is fair, at this point, to say that it's
built into Perl. It's included in most available Perl packages.

> 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?
When I develop software -- like PDF::Writer, which is both an
application and a library -- I want it easily installed on any platform.
That includes Windows and MacOS X. That includes HP-UX, AIX, and Solaris
(none of which Unixes have a half-assed package management system).

> <rant>
> Personally, I don't think software installation is at all the job of
> the language. Software management is the job of the operating system
> (or distribution). It is the very essense of their value-added. It is
> bad enough when some poor schmuck of a user has to figure out and
> remember how to use the package manager of their system, much less
> having to remember a separate one for each language they install
> because they want to use some application.

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.

> Language-specific package managers, in my experience, are often --
> perhaps exclusively -- championed by *developers*.  Never by
> end-application users, because they always suck for casual users.
>
> Ruby is still largely a scripting language.  That is, main *users* of
> Ruby are still people *programming* Ruby for bespoke applications.  I
> suspect that inclusion of Gems will cement that role for Ruby.
> </rant>

I don't think so.

> Incidentally, last time I checked, Gems *still* didn't work behind an
> authenticating firewall, despite the fact that I can get through with
> wget --proxy-user.  There is nothing -- NOTHING -- worse than trying
> to install something that depends on a library that is *only*
> distributed via a gemfile. This makes the package impossible to
> install.

Just a simple question -- how would one authenticate with such a
firewall with Ruby in general?

> Finally, I understand that some people want a CPAN-like solution.
> That's fine. However, I agree with Sam that versioning should handled
> separately from the language-specific package manager. The manager is
> *heavily* dependant on the versioning mechanism, but the opposite
> shouldn't be true. This is poor coupling, exhibits feature envy, and
> should offend anybody with any extensive experience in OO architecture
> and design.

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

I *have* extensive experience in OOAD, and program and API versioning is
one of those hand-wavy things that tends to get overlooked. The RubyGems
folks have actually given some thought on how it might be possible to
fix that.

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