From: "Sean E. Russell" Date: 2005-10-10T21:41:55+09:00 Subject: Re: gems is a language change, not a pkging system --nextPart1258626.pc9opKdtUh Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 28 September 2005 08:54, Hugh Sasse wrote: > I beg to differ: gems do make installation easy, and provide useful > supporting infrastructure for testing and documentation, which means > not only do you get a simple install, but good practices are > encouraged. This cultural stuff is useful. And I think the > simplicity of installing Rails has contributed to its success, for > one thing. That's the funniest thing, because my current objections to Gems are based= =20 largely on multiple bad experiences trying to install Rails through RubyGem= s. > But RubGems doesn't prevent this. If you get a gem and can unpack > it, and then you can repackage it using whichever packaging system > fits your setup, then what is the problem? Specifically: what can > gems do to make [re]packaging easier? Mauricio Fern=E1ndez and Eivind Eklund have covered this quite well, I thin= k. I=20 don't do a lot of repackaging, so I can't contribute anything beyond what=20 they've already said. A long time ago, before REXML was added to Ruby's CVS, I tried building a G= em=20 for REXML, and the experience was an utter failure. I admit that this=20 colored my perception of RubyGems, because even back then people were pushi= ng=20 me to distribute REXML as a Gem. I echoed Austin's attitude toward Debian= =20 packagers. =20 Much more recently, I wanted to evaluate Rails for replacing some=20 infrastructure on a project at work. That, too, was a waste of time becaus= e=20 of the NTLM firewall issue. I think I did eventually get Rails installed,= =20 but it would have been much easier and I would have used less time if I cou= ld=20 have pulled a tar.gz and run setup.rb. I haven't tried packaging recently; if RubyGems solves the firewall problem= ,=20 then I may re-evaluate Gems for some of my other projects. > > I only fear getting locked into using a specific library manager. I (a= nd > > you) expect the following process to occur: =2E.. > Yes, but that doesn't actually mean to the exclusion of other forms. > There will be people making RPMs or whatever. What can we do to > facilitate that? Ruby culture has not been, in my experience, about > the one correct way to do things. I greatly appreciate that sentiment. I suspect that addressing Mauricio an= d=20 Elvind's issues would solve the problem. Somebody else mentioned that bein= g=20 able to pass gem a command that would cause it to list its dependencies wou= ld=20 be a big help. I don't know; perhaps gem already has this. I still have questions about gem's operation. For example, if gem X depend= s=20 on Y, and I've already installed Y but not as a gem, will RubyGems see that= ? =20 If not, then repackagers can't use the pseudo-solution that's been proposed= =20 of just wrapping the gem command. > > 3 Library developers, especially newcomers who've never used setup.rb, > > will only distribute their packages as Gems. > > This is the crux, really, isn't it? I think RubyGems should > facilitate the correct construction of setup.rb based distribution. That would be ideal. > The firewalls issue needs to be addressed, definitely. > What's the nature of the problem? I don't know. That it doesn't work? Honestly, I've spent very little time= =20 investigating it. As I've said, my interest in RubyGems has only gotten=20 smaller with every interaction I've had with it. By the time I got to the= =20 firewall problem, I had neither time nor interest in debugging it. On top = of=20 that, I'm not sure I could justify spending time on it while I was at work,= =20 where I see the problem. > Would your objections still stand if that were addressed? The firewall issue is *my* main issue, and I'd be less hostile towards=20 RubyGems if it were addressed. If the issues around repackaging were dealt= =20 with, then I'd probably feel OK about the system. I'd have to have a bette= r=20 experience with packaging my own gem before I could become an advocate. None of this will address the fact that I still firmly believe that the=20 versioning system should be external to RubyGems. I don't believe that it= =20 must, or should, be so tightly integrated. For one thing, it means that co= re=20 libraries will never be versioned, and there's no reason why they shouldn't= =20 be. It is still much easier to fix bugs by upgrading a single library than= =20 upgrading an entire Ruby version -- for one thing, it allows core library=20 developers to push fixes more often than Matz offers new releases of Ruby. > > "Carthago delenda est!" -- The versioning mechanism must be separate > > from > > My latin's not up to that. =2E.. > than disowning the problem, which won't just go away. Why is such > support worse? "Carthage must be destroyed." There was a Roman senator named Marcus Porci= us=20 Cato who would end every speech with "Ceterum censeo Carthaginem esse=20 delendam", which means "And so, I conclude that Carthage must be destroyed.= " =20 It didn't really matter what he was talking about... he said it endlessly,= =20 interjecting it into every conversation. I was alluding to the fact that I feel the same way about the versioning=20 issue. I believe library versioning should be independant of RubyGems, and= =20 that RubyGems should be dependant on the versioning. Right now, they're=20 co-dependent, making versioning useless to anybody not using RubyGems. It = is=20 in this way that the support is worse. Or, rather, it isn't that RubyGems *uses* library versioning. Gems advocat= es=20 continually misunderstand this, which means I'm not communicating it clearl= y=20 enough. I think it is *great* that RubyGems uses library versioning. I=20 think versioning is so greate that *every* package should use versioning. = =20 Unfortunately, versioning is tied so tightly to RubyGems that it *can't* be= =20 used outside of RubyGems. =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) --nextPart1258626.pc9opKdtUh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux) iD8DBQBDSmBVP0KxygnleI8RAtxGAKCmgGBVWRiTw7IC5hHkf0V7J4IDCwCfYtxG 8NX1++Ki3Xlsinu1+1BfkRM= =oF7R -----END PGP SIGNATURE----- --nextPart1258626.pc9opKdtUh--