Quoting rich / infoether.com, on Fri, Mar 04, 2005 at 12:47:34PM +0900:
> On 3/3/05 10:35 PM, "Sam Roberts" <sroberts / uniserve.com> wrote:
> 
> > 
> > The gem tool (and rpa, I assume) when it packages something up, what it
> > is really doing is enforcing a structure, so tools can work with it.
> > This is cool.
> > 
> > The way I see it is:
> > 
> >  - gems is a nice packaging system, with the unacceptable overhead of
> >    a poorly considered versioning system
> > 
> >  - rpa is a nice packaing system, with the unacceptable overhead of
> >    an external evaluation process
> > 
> 
> I thought for a while if we had a...
> 
> gem deploy (list of gems or --all)
> 
> ...which deploys all the (ruby/native) libraries in the gems into a central
> dir (like the standard /usr/local/lib/ruby/site_ruby/1.8 or something) then
> you could have the normal 'require' stuff just work (removing gems from the
> runtime) and making it just a deployment system.  What do you think?

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.

Why isn't the entire versioning thing optional? I know I'm not the only
person who doesn't like it.

As I understand it, the real benefit to keeping the installs out of the
main tree is that it makes it easy to uninstall, not that it allows
versioning.  Uninstall is very important, but there are other ways of
dealing with that.

The versioning behaviours of gems should be optional, and your deploy
should be standard. If folks need different rails installs, and they
want to use gems in their apps then they know what they are doing, they
should do a

  gem install --versioned

and make sure they do a

  require 'ruby_gems'
  require 'rails', 0.13
  
at the top of their scripts.

Likewise, people who do a gem install --versioned of my libraries
(net-mdns or vPim) will KNOW that my mdns.rb script won't work out of
the box for them, they are going to have to do something to make the
scripts use the particular version - but they deliberately installed
like this, they know what the workarounds are, and why they are doing
it.

Versioning is a special case, it should be treated as such.

> You could even have sets of gems based on a quality estimation (or version
> compatibility) that would give you an RPA style check w/out the packaging by
> a central entity.


I know the rpa and gems team are friendly, so I assume that the RPA guys
real goal is a coherent set of packages. I wonder it they might not
adopt the gem package format if there was a way for them to have a named
set of gems as a "coherent version", or whatever they are looking for?
Particularly if it didn't have the versioning/API change problem?

I have the impression the rpa tool was developed as a side effect, their
primary goal was producing a stable, tested, library distribution.

Sam