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

Well said, Gavin!

Curt

On 10/10/05, Gavin Sinclair <[e-mail]> wrote:
>
> 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
>
>