From: Gavin Sinclair Date: 2005-10-10T23:26:46+09:00 Subject: Re: gems is a language change, not a pkging system On 10/10/05, Sean E. Russell 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�ndez 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