Re: gems is a language change, not a pkging system

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 
largely on multiple bad experiences trying to install Rails through RubyGems.

> 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疣dez and Eivind Eklund have covered this quite well, I think.  I 
don't do a lot of repackaging, so I can't contribute anything beyond what 
they've already said.

A long time ago, before REXML was added to Ruby's CVS, I tried building a Gem 
for REXML, and the experience was an utter failure.  I admit that this 
colored my perception of RubyGems, because even back then people were pushing 
me to distribute REXML as a Gem.  I echoed Austin's attitude toward Debian 
packagers.  

Much more recently, I wanted to evaluate Rails for replacing some 
infrastructure on a project at work.  That, too, was a waste of time because 
of the NTLM firewall issue.  I think I did eventually get Rails installed, 
but it would have been much easier and I would have used less time if I could 
have pulled a tar.gz and run setup.rb.

I haven't tried packaging recently; if RubyGems solves the firewall problem, 
then I may re-evaluate Gems for some of my other projects.

> > I only fear getting locked into using a specific library manager.  I (and
> > you) expect the following process to occur:
...
> 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 and 
Elvind's issues would solve the problem.  Somebody else mentioned that being 
able to pass gem a command that would cause it to list its dependencies would 
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 depends 
on Y, and I've already installed Y but not as a gem, will RubyGems see that?  
If not, then repackagers can't use the pseudo-solution that's been proposed 
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 
investigating it.  As I've said, my interest in RubyGems has only gotten 
smaller with every interaction I've had with it.  By the time I got to the 
firewall problem, I had neither time nor interest in debugging it.  On top of 
that, I'm not sure I could justify spending time on it while I was at work, 
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 
RubyGems if it were addressed.  If the issues around repackaging were dealt 
with, then I'd probably feel OK about the system.  I'd have to have a better 
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 
versioning system should be external to RubyGems.  I don't believe that it 
must, or should, be so tightly integrated.  For one thing, it means that core 
libraries will never be versioned, and there's no reason why they shouldn't 
be.  It is still much easier to fix bugs by upgrading a single library than 
upgrading an entire Ruby version -- for one thing, it allows core library 
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.
...
> 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 Porcius 
Cato who would end every speech with "Ceterum censeo Carthaginem esse 
delendam", which means "And so, I conclude that Carthage must be destroyed."  
It didn't really matter what he was talking about... he said it endlessly, 
interjecting it into every conversation.

I was alluding to the fact that I feel the same way about the versioning 
issue.  I believe library versioning should be independant of RubyGems, and 
that RubyGems should be dependant on the versioning.   Right now, they're 
co-dependent, making versioning useless to anybody not using RubyGems.  It is 
in this way that the support is worse.

Or, rather, it isn't that RubyGems *uses* library versioning.  Gems advocates 
continually misunderstand this, which means I'm not communicating it clearly 
enough.  I think it is *great* that RubyGems uses library versioning.  I 
think versioning is so greate that *every* package should use versioning.  
Unfortunately, versioning is tied so tightly to RubyGems that it *can't* be 
used outside of RubyGems.

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