Re: RubyGems in Ruby HEAD

> It seems to me that rubygems is going some of the way towards making
> this easier:- gem help unpack gives
> 
> Usage: gem unpack GEMNAME [options]

[snip]

> What could be added that would facilitate creating package/rpm/???
> for those who need to?  Given that we are discussing a TODO list at
> the moment...

Yes, that is useful -- though thanks to Mauricio Fern叩ndez, the gem
format is a tarball and not that hard to unpack anyway.

The real trouble comes from gems altering the way ruby works. There's
code out there that requires gems, there's code out there that assumes
ruby works the way ruby works without gems, so loading gems /at all/
will break other things. And now with some libraries being distributed
both only as gems and with hard dependencies on it, that's where life
gets tough.

> > Indeed.  Note that this is partly due to a different point of view.  For
> > Debian we package the libs and apps ourselves.  I hate to say it but
> > there is almost no need for RubyGems in our case, whereas it is very
> 
> Except that rubyists expect things to work cross platform.  So how
> can we add things to make it easier?

Make sure that the semantics of require are the same in both cases.
Don't mess with the load_path silently.
Eliminate any need for authors to require 'rubygems'; the RUBYOPT way is
really good -- if that were the only way to make gems alter the ruby
environment, that would be wonderful, so that code doesn't depend on
rubygems itself, just on the things it actually depends on -- other
related libraries.

> >
> >>> * in general, problems due to the new directory layout
> >>
> >
> >>> Each of these items means additional work when packaging a .gem: the
> >>> source code must be patched before the actual repackaging work can be
> 
> Is there a limited set of things that you need to patch to do this?
> Presumably it would then be possible to integrate this into the gem
> command....  Rather like $ patch < boilerplate;

Depends on the code. Some gems are trivial.

Rails is a couple hours of work to patch. Rubygems dependency it pretty
deep there.

> >> Those solutions may involve changes that can only happen when RubyGems
> >> is incorporated in Ruby, but let's be realistic here.  If the RubyGems
> >> developers aren't involved in repackaging efforts, those issues are
> >> going to end up being low on their priority efforts unless someone
> >> comes to them with concrete problems *and suggestions for solutions*.
> >
> > Ok.  Some concrete stuff then.
> > * Upstream should only have to create a spec file, not change stuff in
> >  the code, let 'require "foo"' stay 'require "foo"'.
> 
> You can get the gemspec out now.  I'm not familiar enough with
> Debian to know what more info you'd need added to it, but that
> seems, from my limited understanding, to be a good place to store
> this info.

The salient point is 'let "require 'foo'" stay "require 'foo'"' -- that
would help most of my repackaging woes too.

The other assumption -- and a tough problem to address in general -- is
where to locate _non-ruby_ data files. In gems, it's
File.dirname(__FILE__) or so -- data lives in the ruby datadir.

The FHS that many linux distributions follows says it should
be /usr/share/#{packagename}, or something more generic, if it's a
pixmap or font resource particularly.  The reason for it? Keeping things
that should only be on the system once on the system just once. Imagine
trying to update a font when every app that uses it has its own copy. To
move from version 1.0 to version 1.1 of a typeface, you have to locate
and replace the old copies.  If there's a central location, you update
just the one.

Don't laugh. I have had to do this many times, and it is a general
problem, not limited to fonts.

> > * Create some generizable installer, maybe assist with Package[2] or
> >  come up with something better, definitely useful to have a
> >  distutils[1]-alike system in Ruby Core IMO.
> 
> I think this is a big project:  I know of ZIP, tar.gz files, Sun
> package files, RPMs, and it seems no-one has found the be all and
> end all of installers.  This problem needs to be bounded more, I
> think.  If we are aiming for 1.8.4 anyway.

What would help more than anything is having an inspectable place to put
data files, that works akin to rbconfig. At the moment, the only way to
locate data files is by configuration, in every library that uses them.
Ruby has no central config file like PHP for this, so every library
hard-codes paths as robustly as the author thinks neccesary, which is
never a complete solution.

If ruby had a datadir mechanism, and perhaps even a path-searching
File.open-alike method that would try each until it found one, the
problem could be neatly solved that would make both gems and non-gems
libraries robust, and provide an elegant mechanism that no other
language provides natively.

It is undoing the assumptions that one gem = one dir that makes
repacking them hard. With PLD in particular, we're trying to solve
problems with a dual-architecture system like Linux/AMD64 and
Linux/Sparc64, where the CPU can run two different kinds of code. Having
things split up in FHS fashion lets one install packages from both
architectures, allowing both 32-bit and 64-bit versions of things to
run. This is entirely out of rubygems scope, so what I'd hope to see is
simply the tools to let this be possible. A good datadir mechanism, and
just trying hard not to make assumptions about the relative locations of
files would help immensely. If this gets added to the ruby stdlib or
core, and gem authors were encouraged to use it, then my work would be
much easier -- debian's too -- and we'd make more progress on making the
ruby packages truly friendly, easy to use and complete.

Aredridel