From: Sam Roberts Date: 2005-03-04T14:37:28+09:00 Subject: Re: ruby gems, and the require problem (was Re: RAA Status & b) Quoting rich@infoether.com, on Fri, Mar 04, 2005 at 02:11:16PM +0900: > > > > On 3/3/05 11:53 PM, "Sam Roberts" wrote: > > > Would be a work-around, and I'm afraid it is oriented at the installer > > of gems, so speaking as a library packager, it doesn't solve my > > problems. > > > > The command line tools I make that use my libraries, they do a > > "require", only. If "deployment" doesn't occur, and its an optional > > second step, the gem users who don't do the > > > > gem deploy net-mdns > > > > are going to be coming back to me and asking why my mdns.rb script won't > > find net/mdns. IMHO, if deploy doesn't always occur, it still leaves me > > with having to maintain different versions of scripts and libraries - > > gem using, and non-gem using. > > No...they need to get your library: > > gem install net-mdns > > And if they have RUBYOPT=rubygems They don't, so the script won't work. > Their code looks like: MY CODE. IT'S MY CODE. Argh. I wrote the script, I put it in the package, and I have to make two versions of it, one assuming that my package was installed with ruby gems in default mode, the other assuming ruby gems wasn't used or that the user did "gem deploy". gems has created two distinct dialects of ruby, one uses ruby's require, and the other uses the gems require, of the same name. Code written in ruby's dialect won't work with gems without hacking the code, or hacking the environment. Code written with the require_gems won't work for people who don't have gems, even if they have the libraries. Its a language split. It's a problem. Having to set 'magic' environment variables or hack the code or command line is a problem, not a fix. > require 'net/mdns' > > If they don't have the RUBYOPT, or don't want it, they can do: [snip] complex work arounds for a problem that should not have been caused > The thing is you assume they install your net-mdns in site_ruby which may > not be what folks want. You need to have two steps...get the NO. I don't assume they install in site_ruby, I assume they install somewhere where ***ruby's require can find it***. That can be anywhere, but if its not in the DEFAULT locations, then they are doing something special, and *they* have to do something special to compensate, like use -I or -rubygems in RUBYOPTS. Note that that is RUBY's require, not gem's require. People aren't using gems for the most part because they want versioning, they are using it because they want packaging, but they are being forced to hack their environment as if they had done a custom install into a non-standard location, when all they wanted was a simple tool to download and install a library. Why? [snip] description, yet again, of how gem's require is better than ruby's because it implements versioning... and all you have to do is hack your environment, change the way you call ruby scripts, or change (just a little bit) of code in all your scripts * Versioning must be optional. * Installed packages must be available with RUBY's require. * A package manager that doesn't install things by default where RUBY can find them isn't a ruby package manager, its something else. People who want to install packages in non-standard locations and use a version selection system can, and if ruby gems gives a standard framework to do that, great, but it needs to be optional. Sam