Rails? Stay the f* away from my system.
I knew for a long time that rails is somewhat fun to work with. The first time I read something about it, I went to check it out, and kindof liked the idea. Web development really isn't my cup of tea, so I didn't do anything with rails; but really, the idea made somewhat sense to me.
It's unfortunate that the implementation is such a piece of crap. Luckily I don't have to deal with it firsthand, but the stories I hear and read everywhere speak for themselves. I won't enumerate them all; but in case you're not familiar with them, the Debian Ruby team has a pretty clear explanation on their website. In addition to complaints by packagers, I also hear that many ruby developers recommend that you install gems inside the project you're running (or that you ship your software in such a way that it includes those libraries as part of your source). Oh, the horror.
Now, however, they've really topped it. Via Koen's blog, I found some other page that contains this:
Now, in theory, to update to the latest version of RubyGems, you just need to run
sudo gem update --system
But - depending on what version of RubyGems you have installed, running that command may lie and tell you that you have nothing to update. If you’re currently on RubyGems 1.1 or 1.2, you need to run a different set of commands to update RubyGems:
sudo gem install rubygems-update
sudo update_rubygems
Seriously. This is why we have distributions, packagers, and, really, people spending a whole shitload of time making sure everything works together nicely. This is why there is Debian, RedHat, CentOS, Mandrake, SuSE, and whatever.
Me touching rails? Not with a 10-foot pole. Not if you pay me a million, in any currency. Stay away from my system!
RoR comes from people who mostly have a MacOSX and Windows background and, at least on the latter, packaging is known to be really poor. But then again, almost everyone deploys those apps to production systems running Linux or *BSD. It's the same annoyance with PHP/PEAR though, a native half-assed "packaging" system that doesn't blend into the native one.
Shipping dependencies within the project itself isn't all that bad though, at least you mostly remain isolated from whatever updates the sysadmin aptitude's on the host. The drawback, of course, being that when it is in order to fix a security vulnerability....
Unfortunately, it's really difficult to bridge Ruby gems with dpkg/rpm packages. Not having portable APIs/tools to create packages for dpkg and RPM (and ...) based systems clearly doesn't help though
At least Python's setuptools has the option of creating RPMs (not exactly as good as a proper .spec file but well, not all that bad either).
Really now. Are you seriously writing an article bashing a framework that you admit that you have never used? You thrash it based on some articles you have read on the web? And you also state that you don't do web development?
And you think I should listen to you why?? What qualifications do you have to open your mouth on the topic?
Shut the f* up.
While agree rails has it's issue how many times have I had to fight apt-get to get something properly installed, broken by a variety of outdated and incompatible dependencies? Not to mention what they consider good application structure...
/var/apache #some files /etc/apache #config shit /log/apache #logs
How is that better than being able to install apache anywhere on a system and having it be a full application package
/var/apache/all_apache_subdirectories
every time I set up or install something on linux I have to search around for various log, config, and actual files which is a nightmare.
I'm really confused. Do you have a problem with ruby gems or rails? Ruby gems is a method of distributing ruby packages on any platform. It also allows ruby apps to use different versions of packages on the same system - very useful for shared web hosting for example, where you may have sites running on different versions.
Rails the framework has nothing to with gems specifically other than it being a method of distribution.
If I've missed your point, do clarify.
The problems you are describing are not problems in Rails, but problems in Ruby. They are not the same thing!
Also, I can tell you from experience that rubygems gives you less headaches then for instance apt-get. Once you get it running (which is relatively painless, the problems you describe are well documented), it just works!
You really shouldn't knock it before you try it...
You seemed to be confused. The RubyGems system has nothing to do with Rails other than Rails packages exist for the gem system if you choose to install Rails that way.
Now if we assume you mean RubyGems and not Rails then maybe we can have a thoughtful discussion. The RubyGems system is certainly not perfect. That is why it is not even part of the standard Ruby distribution (although all indications are that it will be in future versions of Ruby). But it is solving two real problem that other package management systems are not addressing:
Easily allowing multiple versions of the same library/program to be installed. DEB, RPM, etc don't handle this well (they usually end up with some sort of mylib2 mylib3 hack).
Easily allow one package to be used on multiple operating system. Doing it your way I need to make a .rpm (probably several for each Redhat-based distribution), a .deb (again several for each Debian-based distibution), a .msi (for Windows and probably multiple for this also) and a .app (for Mac). And that is just hitting the main systems. That doesn't count the hundreds of systems that don't have any package manager or have some unheard of package manager.
Rubygems solves both of these problems reasonably well. Yes it doesn't integrate with the native package manager and that is unfortunate to loose the consistency. Also there are probably some things that rpm, deb, msi, etc do well that .gem is not doing as well. But as a Ruby developer I can live with that in exchange for my install instruction to be:
gem install myapp
regardless of the OS. And I only have to develop one package. Not perfect but it is better than the autoconf, multiple package hell that many other environments face. And of course there is no reason software cannot start as a gem (for people close to the ruby community) but as it's popularity increases packages can be created that are more tightly integrated into the native package manager.
Two other points:
I agree, RoR developers mostly work on proprietary systems and therefor don't really have an allegiance to one platform over another. This, in a way, shows how far things have come. It used to be if you wanted to develop for Windows, you used VisualStudio, if you wanted to target OS X, you had to dive into Objective-C, but Ruby has flourished, along with perl, python, etc. on these platforms.
This shows that the platform doesn't matter to a lot of developers any more - they are targeting the web, not an OS. But a good OS is still hard to do and web developers are not necessarily the most qualified to discern the details of File system implementation, compilers, and the like, since they never deal with those things.
Plus a good OS, like debian, is getting harder to do. It needs to accommodate not just the web developers slinging ruby, but the cluster people who want high availability, embedded people who want C and small tools, and those who are trying to do high performance computing.
That is why I think it is best that ruby accommodate debian and make a more generalized way of installing software. If they don't they are surely doomed to repeat a lot of fun dependency hell.