hoodwink.d enhanced


The Coast is Clear to Vocally Praise RubyGems #

by why in inspect

For awhile, the Ruby packaging playing field was utterly undecided. Can you imagine that just summer-before-last your only real option was to use raa-install, which was great, but sort of depended on the right install scripts and proper URLs in the RAA. It was a cool hack, thankyou Patrick May.

RubyGems is excellent and has been a huge boost to the proliferation of libraries. It’s features are impressive. Here is what I mean.

Getting library versions with introspection. I’m not sure why loaded_specs is hidden.

 require 'rubygems'
 require 'builder'

 class << Gem; attr_accessor :loaded_specs; end

 # Other metadata, of course...

Serving up all your system’s gems. And documentation for all of them, which we love already. But if you want to check your remote machines to see what’s installed…

On the server: gem_server.

On the client: gem list -r --source http://that.machine:8808.

Searching gems. I have a tendency to pipe the gem list through grep when I’m searching. Here are commands for gem’s own built-in search.

Short: gem q -r -n webdav.

Or completely: gem query --remote --name-matches webdav.

said on 24 Aug 2005 at 23:22

The guys have definitely done a bang-up job, and I couldn’t have asked for a better group to bring my old dream alive.

One of these days I’ll even try to contribute something, hehehe.

MrCode (aka Ryan Leavengood, aka the Guy Who Was Sort of Forgotten When He Stopped Work on the Original RubyGems)

said on 25 Aug 2005 at 01:07

Mrs. Charles McClusky of Peoria, Ill. says: “RubyGems has changed my life! I’ve lost 20lbs and I look 10 years younger. The only thing I can’t figure out is why I keep craving Japanese food – I never had Sushi before this. Pass the uni please!”

Mr. Clyde Sanderson of Milwaukie Wisc. writes: “Thank you for RubyGems! I’m catching more bass than I ever could’of imagined! My wife is even going to let me buy a new boat!! Hey, but one question: Why do all the ducks out there in the pond seem to have little horses climbing on their backs?”

Welll, maybe Mr. Sanderson has had a little too much RubyGems. Remember RubyGems are powerful!

RubyGems! Snakes don’t like them! Watch what happens when our non-RubyGems-using friend jumps into this snake pit – Ugghhh!! not pretty. Now watch what happens when this smart fellow jumps in the snake pit with RubyGems™; they don’t bite, they don’t even lite!

RubyGems™: Available without a perscription. (not available to Pythons; Oyster eaters and Java drinkers may need some time to adjust to RubyGems. )

said on 25 Aug 2005 at 04:11

IMO rapt worked great too.. Btw, I’m still keeping the hope that the rubygems guys can change #require_gem to #use or something else. Quick, before the 1.0 come!

said on 25 Aug 2005 at 05:25

Actually, I’d rather have that gems be indistinguishable from normal packages, and just use “require” like others (without having to require “rubygems” either). End applications shouldn’t have to know about the package manager. They shouldn’t have to know about whether a package they depend on has been installed through Rubygems, by hand or through a third-party distribution mechanism like apt.

As long as Rubygems is not transparent to me as a programmer, I’m afraid I’ll have to do without.

said on 25 Aug 2005 at 06:55

Yeah, the require_gem thing is a bit annoying, you can do a workaround by rescuing an exception (as outlined in pickaxe2). Pickaxe2 also claims that as of rubygems 0.7.0 it generates ‘stubs’ to make require work normally, but that doesn’t seem to work on my system.

said on 25 Aug 2005 at 07:39

They got rid of stubs. You can not set the ENV var RUBYOPT to allow require to automatically search the gems.

In part I agree with Tsela. But versioning is a good thing, and I suspect there’s no way to have both worlds—some file sysmes don’t have linking. So it’s either this or stubs.

Why were stubs given up?

said on 25 Aug 2005 at 08:16

Maybe it’s just me, but I’ve had nothing but pain from gems. I’ve tried to install rails several times with it, and always got mysterious and unhelpful errors that nobody could explain. Meh.

said on 25 Aug 2005 at 10:48

If you need versioning (and you KNOW the lib was installed via gems), there’s no reason you can’t use the current method of require_gem. However I think if you don’t care about versioning, or can’t gurantee gems is managing the lib, that you should be able to ‘require’ it, regardless of how it was installed.

I don’t think you’d need to use symlinks for stubs, couldn’t you use a ruby file that added the gems lib path to the search path, and then required it. You’d just need to change the search path depending on the version of the lib you’re making a stub for… Tho, what do I know? :)

said on 25 Aug 2005 at 11:25

What, my current method of olfactory praise isn’t good enough?

said on 25 Aug 2005 at 13:38

require_gem and require can’t be actually mixed since the former does not really load a file like the latter does. That’s why I’d love to see the name changed, it does basically a very different thing then “requiring”.

said on 25 Aug 2005 at 16:05

Hurrah for rubygems!

Matz says:

I just don’t want to discourage one side by merging another. If RPA camp say “OK, we go our way, nevertheless Gems merged in the distribution”, that’s fine for me. Did they?

The time has come.

said on 26 Aug 2005 at 06:32

Thank you, Why and everyone!

Some answers to the questions raised:

  1. Stubs: All of this require_gem/RUBYOPT/stub stuff is a placeholder until we’re integrated into ruby core. The require override is a much cleaner placeholder than the stubs.
  2. Transparency: There are very few instances of things not being transparent to programmers, but I know some exist. If you use RUBYOPT (or somehow externally required “rubygems”), you will likely not run into any issues.
  3. “require_gem” vs. “use”: We’ll probably rename “require_gem” pre-1.0.
  4. jason: Can you email me with the issues you’ve had at chad (at) chadfowler.com?
  5. Inclusion in core? This is a question that’s been lingering on ruby-talk since Mar. 16, though I hear that Matz mentioned RubyGems in his OSCON talk saying that there was no need to bundle additional libraries with core any longer since it’s so easy to install things with RubyGems. I’d say that’s a pretty good indicator. If we don’t have an answer by RubyConf, we’ll get one there. Slow and steady….
said on 26 Aug 2005 at 12:11

Rubygems is an excellent package management system. The one place I’ve had trouble with it has been with native extensions though. I know this isn’t ruby gems’ fault, but it’s still an issue. Any ideas on what it would take to make it easier to install some packages in Windows?

Don’t worry I use OSX whenever possible, but folks I work for like Windows since they believe they can administrate it ;)

said on 26 Aug 2005 at 12:42

Too bad it still doesn’t play with dpkg, pacman or rpm.

I loathe the thought of having to use two separate package managers to maintain my server cluster rather than one. With 13,000 packages available in RPM , and a few hundred in gems, the choice is clear.

said on 26 Aug 2005 at 12:56

Hey, this is like watching Fox News’ debates.

said on 26 Aug 2005 at 17:35

I really appreciate the central aspect of gems, and how easy they are to create/distribute, but my problems are thus:

1) The command line syntax just seems awful to me. Not like any other familiar program, switches required when they shouldn’t be, long syntax, etc.

2) It doesn’t play well with package managers. I use gentoo, and when a package is available through portage and a gem, I choose portage. It knows my system better. So I lose out on gems’ consistency, can’t follow procedures consistent with other people, and, of course, gems doesn’t know that I already have certain libraries installed.

3) I’m afraid Tsela is right, it’s not transparent enough. If/when it gets merged to Ruby officially, and if it can become totally transparent with require, it’ll be fantastic.

Comments are closed for this entry.