This post originated from an RSS feed registered with Ruby Buzz by Norman Richards. Original Post: site directories and programming languages Feed Title: Norman Richards Feed URL: http://members.capmac.org/~orb/blog.cgi/tech/ruby?flav=rss Feed Description: peace, love and burritos Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Norman Richards Latest Posts From Norman Richards

Spending the weekend in Ruby-land has made me think a lot more about the possibility of developing applications in Ruby. One of the biggest problems, as I see it, is the role that site-ruby plays. If you aren't familiar with site concept, the idea is that there is one place on the system that third party libraries can be placed. Once placed there they can be accessed from any ruby application. The java equivalent would perhaps be lib/ext, but anyone suggesting placing libraries there for a shared JVM install would likely be shot on sight. (perhaps even on site)

I can see the role that a site install directory plays in providing an end tool. Emacs has a site install directory, for example. It makes sense to install add-ons to tools in a site-wide manner. But I think it's just plain wrong to pollute the language install directories with third party libraries.

As a programmer, I want to know that I can count on a standard, pure environment. I don't want to tell you users that they need to install 10 additional modules just to run my app. I would prefer to provide them myself. As a user, I don't want to have to allow third party libraries to write into my install directory. And, I certainly don't want ot "sudo ruby install.rb". Yuck! One of the reasons I refuse to use perl is the need to compile in 500 third party libraries to run perl programs. I'm not eager to start doing that for the sake of ruby either.

Maybe this is my Java bias showing, but Java definitely has the right approach here. (even if the details are messed up) In the Java world we still haven't figured out how to version jars in a useful way or how to declare dependencies in anything more clever than brute force classpaths. (well, I guess there is JNLP) However, the general approach of bundling code into jar files local to the application being run seems to solve a lot of problems. (at least I don't have to sudo to make anything run) I'm told .NET assemblies are a better approach, but I just can't motivate myself to really care about anything happening in the .NET world.

I should ntoe that I did see something this weekend called a ruby gem file for packaging ruby libraries. But it looked to me like the gem file was more like an RPM than a jar file. If that is true, I think it is the wrong approach. The goal shouldn't be to make it easier to instlal libraries, but to make it unnecessary to install libraries. But that's just my opinion...