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

Ok, in an attempt to reduce clutter, I'm responding to several people in one 
email.  I don't think anything new is being said by myself, anyway.

On Monday 10 October 2005 09:31, Hugh Sasse wrote:
> > 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.
>
> Except that doing so even to the extent where we get a stackdump
> might make life much easier in the future.  If you can show us a
> failure, others who have more time may be able to reproduce it and
> help us squash it.

I need to be able to justify the time expenditure, and I can't.  I'll try to 
install something and see if I can get an idea of where it fails, but beyond 
spending a couple of minutes on it, I'm just stealing the client's money by 
working on this.


Later, Gavin said:
> Rails has always been available as a tarball. eople should really
> stop griping about this aspect of the debate.

It has been a while, and I could be misremembering, but I remember it being a 
real PITA trying to find the tarball for Rails.  I see the "tar/gz" releases 
to the left now, and maybe they've always been there.  If so, my mistake.

> But what's so doggone hard or objectionable about installing gem Y if you've
> already  installed gem X?

You misunderstood me.  I've already installed Y, but not as a Gem.  Now I try 
to install X (which depends on Y).  What happens?


Even later, James Britt wrote:
> Perhaps I'm misreading you, but you seem to prefer tarballs over gems 
> because gems does not solve the firewall problem. ut neither does tar.

You're right.  Tar doesn't try to do any network traffic, and I can inspect a 
tar and see what it is going to do to my system.  But, if it is as you've 
said, I should be able to download a gem, get a list of the gem dependencies 
(some of which I've already installed without RubyGems), download those 
dependencies which I don't have, and use 'gem' to install them from the 
command line without 'gem' trying to go to the network.  In that case, the 
firewall issue isn't a big deal, and you're right that I'm in no worse 
position with Gems than without them.


And way later than that, Chad Fowler asked:
> Sean, what were you using before REXML was added to Ruby's CVS? e 
> wrote RubyGems after that. ere you
> using Ryan Leavengood's old prototype? f so, that's only related in 
> name and purpose.

That's probably the case.  I haven't been following the evolution of RubyGems.

Although, more recently than this I tried to build a Gem for SVG::Graph, and 
had the build process fail on me with some script error that I didn't try to 
track down.  This would have been, oh, about a year ago.


And finally, Jim Weirich asserted:
> > I still have questions about gem's operation. or example, if gem X
> > depends
> > on Y, and I've already installed Y but not as a gem, will RubyGems see
> > that?
> 
> No. ut it doesn't prevent you from installing the gem. ou can tell the
> gem command to bypass dependency checking with a command line option.

Will the Gem work?  I mean, without the dependency stuff, will it find the 
requires that it needs?  Installing it is only half the problem; it still has 
to work.

That's good to know about being able to bypass the dependency checking.

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