From: Eivind Eklund Date: 2005-10-03T17:49:29+09:00 Subject: Re: why can't Ruby load .gem files directly? On 10/3/05, Austin Ziegler wrote: > On 10/2/05, Devin Mullins wrote: > > Eivind Eklund wrote: > >> On 10/2/05, Devin Mullins wrote: > >>>`gem uninstall thegems` > >> What if other stuff rely on those gems? Like user-written code? > > OK, point. What does apt-get (or ports) do natively to fix this? > > Nothing. Nothing at all, which makes it something of a nonsense > question. Actually, at least ports does something about this, though it's somewhat subtle: It leaves the dependencies behind, and listable/deletable by the user using the standard tools. This avoids breaking user code, at the expense of fairly often leaving unwanted packages behind. > I'm in the middle of discussions so that we can possibly solve this in a > way that at *least* makes the most complex case feasible without adding > all sorts of nonsense requirements to the developer or RubyGems. I > maintain that RubyGems is the *right* solution for Ruby because it both > helps with package management and with API versioning. 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. I also think that an integration is the way to go. I am uninterested in which package manager does the actual file copy; I just think the metadata (at least that the package is installed) needs to be available from both for things to work right. The FreeBSD CPAN integration is such that when I install a package using CPAN, it show up in the local *FreeBSD* package database, and believe I install a Perl package using ports it also show up in the local CPAN metadata (though I'll admit I never look at that, so I don't know.) This also mostly follow my local operating system policies. I hope we can find some way of achieving the same or better integration with RubyGems - I think the way to get there is to just solve one problem at a time, until things work right. Eivind.