On 10/2/05, Joshua Haberman <joshua / reverberate.org> wrote: > On Oct 2, 2005, at 5:06 PM, Austin Ziegler wrote: >> On 10/2/05, Joshua Haberman <joshua / reverberate.org> wrote: >>> On Oct 2, 2005, at 4:00 PM, Austin Ziegler wrote: >>>> I also believe that the *right* way for package management systems >>>> to work with RubyGems is to *use* RubyGems and the facilities it >>>> offers (or will offer) to install gems. >>> Why? >> Because RubyGems offers several features -- package and API version >> management, easy package install/uninstall, etc. > API version management is great. But you don't need to use "gem > install/uninstall" to reap the benefits of it. Actually, yes, in fact, you *do*. You need something integrated into the language that allows you to have multiple versions of a library installed that does not also moronically lock you into a single version by default (e.g., the sometimes suggested 'require "foo-1.0"' concept). > The package install/uninstall are only easy if your system setup > matches the assumptions implicit in the design of the "gem" command. This is a completely incorrect statement. I'll leave it to the reader to actually *think* the concept through. >>> There are many cases where "gem install" is not suitable, but "tar >>> xf" is. >> I'd love to know one, for a .gem. Seriously. > - you want to install Ruby and a bunch of gems onto a software > partition that will be mounted read-only from tens or hundreds of > nodes. This has nothing to do with RubyGems, and can (in fact) be managed by RubyGems as it stands. This point -- as well as your other two -- are completely irrelevant to RubyGems itself. Suggesting otherwise really indicates that you *do not* understand what RubyGems offers in the least. > The philosophy inherent in "gem install" -- that I am going to > "install" the gem on any machine that will ever run it, and I will > have write access to do so -- is narrow and brittle. Then restrict the availability of the gem command. It's not *that* hard, and suggesting otherwise is a cop out from someone who doesn't get it. >> There's absolutely *no* advantage to untarring a gem, and (IMO) >> serious disadvantages. Why would you even think about forgoing what >> RubyGems offers? > Until you understand the answer to this question, you will not > understand the opposition to your current plans. Until you understand why your question is not only nonsense, you will not understand why I won't accept anything that isn't *centered* around RubyGems. It's attitudes like yours that basically is leaving me with "No Special Treatment For Debian Users With Special Needs." I have no patience for this nonsense. > The answer is: the things that RubyGems offers are not appropriate in > every circumstance. It is great to make things easy for the common > case, but you've got to make them possible for the unusual case as > well. Ruby's packaging system needs to be a tool that skilled > programmers can use to fit their needs, not a policy layer that > demands you do things "the gem way." That's not an answer; that's a cop-out. > I'm not opposed to the existence of "gem install/uninstall." I am > opposed to any attempt to force people to use gem install/uninstall > if it is not appropriate for their situation. It's never *not* appropriate. Just lock down the gem command if you don't want average users using it. But, then, of course, you can't allow *local* gem installs that way, either, and RubyGems explicitly supports that. Which means that you're left with locking down the shared items on a read-only environment and letting Ruby's standard mechanisms for working with the operating system raise exceptions as appropriate. Indeed, most of the time, you want to do: % sudo gem install foo Or you do a local install. Don't throw up roadblocks because you don't understand what is actually offered -- and don't pretend that Debian or FreeBSD's solution is "All That." If it isn't a good Ruby solution, it's not a good solution. Pandering to a single platform is most certainly not a good solution. Pandering to two platforms is equally a bad solution. Pandering to +n+ solutions is even worse. Writing a good solution -- and this *is* RubyGems -- that offers hooks for packagers to use *while using the existing infrastructure* is a much better option for Ruby and for everyone else. -austin -- Austin Ziegler * halostatue / gmail.com * Alternate: austin / halostatue.ca