--nextPart4143664.IJGqfZ9GWs Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 problem= s=20 than it solves. Only people who work with Perl regularly seem to like it;= =20 for users of Perl applications, it is often more of a curse. There are eve= n=20 many Perl developers who grumble about CPAN. However, Perl is stuck with=20 CPAN. It is so intrinsically intertwined with Perl that getting rid of or= =20 replacing CPAN would be an excercise in pain and suffering the likes of whi= ch=20 hasn't been seen since... well, pick your favorite historical ethnic=20 atrocity. However, at least CPAN isn't built into Perl. I don't understand the comment about "those ... who have to deal with other= =20 platforms". What does that mean? From the packager's point of view? From= =20 the library author's point of view? <rant> Personally, I don't think software installation is at all the job of the=20 language. Software management is the job of the operating system (or=20 distribution). It is the very essense of their value-added. It is bad=20 enough when some poor schmuck of a user has to figure out and remember how = to=20 use the package manager of their system, much less having to remember a=20 separate one for each language they install because they want to use some=20 application. Language-specific package managers, in my experience, are often -- perhaps= =20 exclusively -- championed by *developers*. Never by end-application users,= =20 because they always suck for casual users. Ruby is still largely a scripting language. That is, main *users* of Ruby = are=20 still people *programming* Ruby for bespoke applications. I suspect that=20 inclusion of Gems will cement that role for Ruby. </rant> Incidentally, last time I checked, Gems *still* didn't work behind an=20 authenticating firewall, despite the fact that I can get through with wget= =20 =2D-proxy-user. There is nothing -- NOTHING -- worse than trying to instal= l=20 something that depends on a library that is *only* distributed via a gemfil= e. =20 This makes the package impossible to install. =46inally, I understand that some people want a CPAN-like solution. That's= =20 fine. However, I agree with Sam that versioning should handled separately= =20 from the language-specific package manager. The manager is *heavily*=20 dependant on the versioning mechanism, but the opposite shouldn't be true. = =20 This is poor coupling, exhibits feature envy, and should offend anybody wit= h=20 any extensive experience in OO architecture and design. =2D-=20 =2D-- SER "As democracy is perfected, the office of president represents,=20 more and more closely, the inner soul of the people. On some=20 great and glorious day the plain folks of the land will reach=20 their heart's desire at last and the White House will be adorned=20 by a downright moron." - H.L. Mencken (1880 - 1956) --nextPart4143664.IJGqfZ9GWs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux) iD8DBQBDOoPUP0KxygnleI8RAr6XAKCTcY8pWm9g18joH+d/kdp30hd8fgCfWAzl 98aSONbOyRno+nrjD2Ggk6w= =l1iY -----END PGP SIGNATURE----- --nextPart4143664.IJGqfZ9GWs--