Gems
Has it been 4 days already? So it seems, hmmm… days can be sooo full, last Monday I was occupied from 8:15 till over 18:15, I think the Trimester of Hell remark on August 17 wasn’t an overstatement. I mean, it’s only the beginning!
The Ruby Pickaxe 2nd edition is bound to release very soon. I’ve been looking forward to buying this, since the first edition is based on Ruby 1.6, but I’ve been using Ruby 1.8 for months now. I have to say something about these Ruby Gems. Everyone keeps asking me what it is that I have against Ruby Gems, so I’ll try to answer that here. It was conceived as a way, ala CPAN, but then different. Since each Gems is just one directory, this leads to some unclean side-effects:
- You have to install program stubs all over the place, i.e. let
$prefix/bin/programlink to the binary in the gem’s dir so it’s in the user’s path. - Since libraries are distributed as gems too, you can require them. You
can do:
require 'some_gem_lib'But for thisrequireis redefined to search efficiently through all gems. - Since the libraries are located in one directory, programmers can
abuse this by using more relative paths in the code. For example:
require "../../../mylib/a/b/c.rb"This is not at all a best practice and packages packging harder.
Also some stuff learned in other package systems are not used (for now), such as Recommends, Suggests, etc. Also versioned depends are not a required thing, which, I think, shall lead to some chaos. Since the main goal is to create a standard way to distribute code to third party, packager etc. I think they should’ve been more involved. Installing these gems in those directory also violates the FHS, making it all very hard to package for Debian. I’m looking much more at RPA now, which looks very nice and interesting. I hope people aren’t going to distribute their stuff as gems only and also won’t make assumptions based on it if they do.