4 ms·
Far too high a proportion of the questions in #ruby are about installation. Often people come in having (naturally) tried to install it from their distro's pac
by JonnieCache 14y ago
Far too high a proportion of the questions in #ruby are about installation.
Often people come in having (naturally) tried to install it from their distro's package manager. First we have to explain to them why this is a bad idea and persuade them to remove it. Then, often they have tried to install it from source, passing some fucked up value to --prefix, and they have to be helped to clean that mess up.
Then we tell them to use rvm, but someone pipes up about rbenv and friends and we have to explain the differences. Then it turns out that they didn't have openssl-dev or something installed so they have to recompile ruby again, or someone has to try and remember the magic spell to compile the openssl bit of ruby separately, which nobody ever can.
THEN it turns out that all they want to do with ruby is run redmine, which has some other specific requirements that nobody in the channel knows or cares about.
Basically, when yehuda katz finishes that project of his, freenode will be measurably happier, although the problems with OS packages will remain, I imagine forever.
The real root of the problem is that a lot of the things which make the ruby ecosystem highly dysfunctional are the same things that make it so great. Primarily the fast pace.
- davidw 14y agoI use and love Ruby every day, but this package management business is ... irksome. First the Ruby guys crapped all over package management from Debian, who, despite their shortcomings, have been doing it a while and know a thing or two about it. That wasn't entirely unfounded, because there were some messy things there, and the intersection of two different package management systems is bound to be a bit confused. Now we have rvm's and gemsets and bundles and additionally people trying to foist off alternatives to some of these, and the whole thing is beginning to look like an unholy mess. Meanwhile, Debian/Ubuntu's package management continues to work pretty well at what it does.
- mje__ 14y agoUntil you have more than one app running on the same machine with different dependencies... like say on a development machine. This is the point when bundling shines, because it elevates you off of the os-level dependencies.
- davidw 14y agoA properly done OS can handle more than one version of a library at the same time. Also, it's a good idea to use a development environment that's not too far from what you're running in production.
- dasil003 14y ago> Meanwhile, Debian/Ubuntu's package management continues to work pretty well at what it does. But what it does moves at about 10% of the speed of the ruby community (at least post-Rails). I'm not saying that the ruby culture is better—it obviously has serious consequences for stability and leads to all manner of headaches. However it does mean that if a new and better idea of how to do something comes out, Ruby is probably one of the first places you can use it in production. My feeling is that the benefits outweigh the costs if and only if you are a full-time developer in a paradigm that Ruby is good for (eg. traditional web development). If you are just dabbling in the language then Ruby will continuously pull the rug out from under you. And if you are just trying to install some software as an end-user, then Ruby is probably one of the worst possible platforms.
- davidw 14y agoI didn't meant to say that Ruby should use Debian package management or anything like that: it needs its own stuff at its own speed. More that they should be a bit slower on the draw when it comes to pissing on other people's work.
- dasil003 14y agoAgreed that the subset of the community with no respect for the Debian process showed the worst sort of young hipster developer arrogance.
- petepete 14y agoSurely bundler helps solve some of these problems; at least it makes managing gems easier on a per-app basis.
- davidw 14y agoAnd then you try and deploy it: http://serverfault.com/questions/405994/state-of-the-art-deploying-rails-applications-with-git http://serverfault.com/questions/405994/state-of-the-art-dep... And you're either stuck with this Mongrel-derived nonsense that is incapable of utilizing the computing power of the server to dynamically (de)allocate resources, requiring you to pick numbers at setup time, or you've got Passenger, which gets that right, but basically nails your deployment to one and only one Ruby. (Yes, I've not had the best of days...does it show?)