Re: RubyGems in Ruby HEAD

On 9/20/05, Aredridel <[e-mail]> wrote:
> Having Gems become standard as they are now is problematic for linux
> distributors, because of the amount of effort to package them to play
> nice with other software is high.

It need not be, though. Someone recently put various RubyGems packages
in the FreeBSD ports system. It's an imperfect mix, and there are
certain enhancements that can be made to RubyGems to make it *better*,
but that person essentially *uses* the .gem file as the core of the
port. The main work involved, apparently, was getting the RubyGems
command-line application to play nicely.

[...]

> It's a break with backward compatibility to go changing require's
> semantics if rubygems is automatically loaded, and if it isn't, we run
> into more and more libraries and apps that won't work with non-gem
> libraries.

Um. I don't see it as a big break with backward compatibility.
Ultimately, I think that the API will be changed from a single parameter
Kernel#require to a two parameter #require (e.g., "require 'pdf/writer',
'1.1.2'"). But as I said before, I'm not on the RubyGems team, and I
don't really have the time to help them implement anything so if they
choose something other than that, that's just life.

> It's mostly the breaking API that bothers me: changing require's
> semantics, and adding an ever-growing list of libraries that only work
> with gems, thereby requiring all prerequisites to /also/ be gems, is
> making packaging ruby libraries up efficiently problematic. Packaging
> escapes the realm of ruby, and has tentacles into the rest of the
> system.

That should be less of a problem when RubyGems is in the core.

> With RMagick as a gem, and ImageMagick installed with RPM, if I
> upgrade ImageMagick, RMagick breaks. With RMagick as an RPM as well,
> RPM throws a dependency warning, and I can go fix the problem, instead
> of discovering that my image thumbnailing application has been broken
> for days because of the broken dependencies. Fixing that is out of
> scope for rubygems -- it just won't happen, it cannot happen.

Why can't you package some of these things the way that the ports
packaging is done (e.g., a wrapper around the gems)?

> Rubygems works alright for pure-ruby packages, most of the time. The
> edge cases, however, are not rare, and have some grave problems. I
> would like to see those problems addressed, or at least make it so
> that those who maintain projects whose scope does include non-ruby
> libraries can make that happen.

I agree; there are edge cases that I think need to be greatly improved,
and one of those is actually Windows compile support improvements.

-austin
-- 
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]