

Ruby has a distribution problem - luckystrike
http://www.madstop.com/ruby/ruby_has_a_distribution_problem.html

======
petercooper

      For example, rubygems (probably my least favorite ruby
      software of all time) basically require that you always try
      to load them, because their design stupidly requires that 
      you know whether a given piece of software is installed via 
      rubygems or some other mechanism.
    

Nearly all libraries nowadays are installed via RubyGems. For most of its
life, RubyGems has been the "de facto" way to install libraries, but not the
100% officially-sanctioned route. As such, it's necessary to require RubyGems
in first, then the libraries you want to load. This takes all of 10 seconds to
learn.

The poster has missed the point somewhat when it comes to the use of vendor.
"vendor" is used in situations where you have to remain fixed to a certain
version of a certain library AND you're not 100% confident that your
deployment environment will have that version of the library installed. In
this way, it's a better solution than just praying the remote server has a
certain library installed or ending up with a script that fails on the library
version assertion, as with Perl. Overusing vendor is, however, a lazy way of
doing things, and the sloppy programmers this guy has spoken to do not
represent the community as a whole.

From the comments:

    
    
      To me, this is one of the really big things that defines 
      Perl as a mature language community: Perl people don't do 
      this nonsense.  There's no "vendor," and you're looked at 
      like you're out of your mind if you distribute copies of 
      other people's modules with yours instead of declaring 
      versioned dependencies in your Makefile.PL. 
    

(Good) Ruby people don't do this nonsense either. RubyGems supports you
specifying the gem name and required version (or required minimum version) in
a similar, or better, way than Perl.

This is an over-rated post telling us about a problem that only exists in the
ignorant. It's cut from the same cloth as all the misinformed "Twitter's
Dropping Rails!" posts and I'd expect better from the voters on HN.

~~~
luckystrike

      This is an over-rated post telling us about a problem that only exists in the ignorant. 
      It's cut from the same cloth as all the misinformed "Twitter's Dropping Rails!" posts 
      and I'd expect better from the voters on HN.
    

Cross Platform Software Distribution is a _challenge_ for any
language/technology. I guess the upvotes for this submission do not imply
readers here agree with the viewpoint on Ruby given in the article, but rather
think it is an interesting topic worth discussing. (I might be completely
wrong in this assumption)

I am an active user of Ruby, and agree with you that the author is making over
generalized sweeping statements such as: _"yet it's the standard, recommended
practice in the Rails community, because it makes it easy to "guarantee"
behaviour in a given environment"_

There is no silver bullet for software distribution in any particular
language. One has to be smart and pragmatic enough to weigh in the pros and
cons of static linking/vendoring in their particular case, and then take a
wise decision on it.

------
demallien
Swings and roundabouts.

Personally, I use Ruby for stand-alone apps more than for Rails. I do command
line tools and Mac apps using RubyCocoa. I can't guarantee that my product
functions as planned if I can't control what code it uses.

For libs which belong to the core OS, I am comfortable with using shared libs.
These libs are very well documented, and the interfaces don't move. Any
changes made by the OS vendor are generally for fixing bugs.

For everything else, I have no guarantee, and hence little trust, that the
developer isn't going to change their lib in a way that breaks my code. In
such a case, I much prefer to take control over that lib by bringing it into
my own project as a static lib. I give my app it's own auto-updating feature,
and I take responsibility for keeping the static libs up to date. That takes
care of potential security issues.

------
fendale
Not so much a distribution problem, but a platform problem - I cannot get Ruby
to compile on an Itanium HP-UX box - even the HPUX ports site says it won't
work :-(

If anyone has got it to work please let me know!

