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

On 10/10/05, Sean E. Russell <[e-mail]> wrote:
> > But RubyGems 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.

I've never understood the criticisms of repackagers, because I have no
real experience with those package managers -- as a user or a
packager.  Also, I'm with Austin: it's better to target a Ruby
platform than a squillion OS platforms, for libraries anyway. 
Applications are a different story, but they're a minority of Ruby
projects.  Gems is developer-friendly but not end-user-friendly. 
Ultimately, the end user shouldn't have to use it.

There are problems; they need to be sorted out.  But people need to
respect RubyGems for what it is.  It's *better* than Debian in the
sense that it's not bound to the OS.  In other senses, of course, it
may be worse.  I think using an OS package manager to manage non-OS
development libraries is madness, but again, my opinion isn't backed
by genuine experience.

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

Rails has always been available as a tarball.  People should really
stop griping about this aspect of the debate.  Many developers seem to
have this attitude where they want to solve all problems before they
begin.  Rather than scream blue murder about gems taking over the
world when all you want is your tarballs, the following attitude is
more appropriate: if you come across a library you want that's only
available as a gem, ask the author to release a tarball as well.  Show
them how Rake can generate both at once in the blink of an eye.

That rant is not aimed at you or anyone in particular, Sean; just a
dramatisation of the sky-will-fall-down attitudes I sometimes see.

> I greatly appreciate that sentiment [context snipped].  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.

Probably; if not, it's easy to add.

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

I think RubyGems will see that but I'm not sure.  It depends whether
gem X specifies at runtime that it needs a particular version of Y. 
If not, it should be fine.  If so, perhaps not.  But what's so doggone
hard or objectionable about installing gem Y if you've already
installed gem X?

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

Such an ideal needs specification.  But the point (3) above is the
kind of pessimism I ranted about above.  Ruby is an open source
community.  Help each other to maintain a suitable variety of release
formats, people.  Help each other out, for goodness sake!!  Social
solutions complement technological ones very nicely.

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

The standard library could be dropped and released as a bunch of gems
with a "stdlib.gem" tying them all together.  That's just an option
which would allow autonomous update; I'm not advocating it as such.

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

Nobody to my knowledge has ever written so much as a proposal for
integrating library versioning into Ruby.  Do you want something that
works for many use cases, is being improved, has made thousands of
people's lives easier (though a few repackagers' harder), and is
actually a workable Ruby packaging platform?  Or do you want something
that doesn't exist?  I want the former.

What's more, if anyone *did* write a serious proposal and begin an
implementation of a packaging-platform-independent versioning
library/framework/whatever, it would still fall foul of the setup.rb
brigade.  You can't have nice functionality *and* lowest common
denominator at the same time.

Here's a scenario (I ain't predicting the future, just telling a
story).  Ruby adopts RubyGems as its built-in packaging platform. 
It's very successful for many people, but an irritant to some, who
wish manage things slightly differently but interoperate with Gems at
a versioning level.  So they refactor the gems versioning stuff to
interface with other solutions, and away they go.

Nothing needs be final or exclusive.  Things can always improve.  It's
better that things improve than that they don't exist.

Remember, gems only gets into Ruby on Matz's say-so.  So people can
and should complain all they like, but they should have some faith
that a decent decision will be made.

Final points in this long post.  I mean no hostility to anybody,
despite making some robust points above.  I will confess, however, to
being tired of all the negativity and even scaremongering that has
accompanied RubyGems's long slow march to maturity.  Two of the
longest-standing Ruby community members have put a crapload of effort
into it, and many others have pitched in as well.  I don't demand
acceptance of the product on that basis, but I do expect respectful
and constructive discussion.  If they could solve all the problems in
the world, I'm sure they would.  People's expectations in general need
to be realigned with reality.

Peace,
Gavin