Quoting rich / infoether.com, on Fri, Mar 04, 2005 at 02:11:16PM +0900:
> 
> 
> 
> On 3/3/05 11:53 PM, "Sam Roberts" <sroberts / uniserve.com> 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