Can I be the jerk on this thread to raise my hand and say, "from what I can see, every single thing Debian has done with Ruby, from the way they split Ruby up into separate packages to the mindboggling damage they inflicted on RubyGems, has worked to the detriment of Ruby and provided no discernable benefit to end-users"?
For at least a year now, I've simply accepted that Debian's Ruby lives in a parallel bizarro-universe, rm'd any trace of it that intrudes on my own (real) universe, and installed everything from source.
I write this not to feel better about myself but to attract the passionate, angry disagreements that will help me better understand the problems this guy was trying to solve, so I can understand how he looks at the world and what his decision means instead of silently hoping that this post means nobody is going to try to integrate Debian and Ruby anymore.
You've done the right thing, but attributed blame in the wrong place, it's Ruby that's in the parallel bizarro-universe.
Ruby, RVM, ruby-gems etc were all designed and built for developers. APT was designed and built for system administrators.
In the world of system administrators, API differences between versions 2.3.5 and 2.3.8 would be considered bugs. In the world of Ruby/Rails, that's just standard practice. APT would not let you install both 2.3.5 and 2.3.8 simultaneously because that would be silly. It is silly, but it's useful for developers. The detriments are obvious to everybody but the Ruby community -- DLL hell is one of the major factors in the decline of the Windows platform.
So yes, keep Ruby off in it's own parallel universe, partitioned off using RVM or bundler. As a developer, this brings you many real benefits. But recognize the real detriments to normal users and system administrators, and place the blame squarely where it belongs -- on the Ruby community.
Ruby is overwhelmingly used by developers. I understand that there are a few projects that are so popular and useful that end-users and admins might want to install them without actively developing for them. But the decision to optimize Ruby for that use case, instead of for its overwhelmingly more common use case as "developer tool", just - seems - wrong.
I don't "blame" anyone. I think Debian is wrong about Ruby.
But is that a coincidence? Python is widely used by end users -- a large portion of the Ubuntu apps are written in Python. Ruby is widely used by end users via the web (zillions of twitter users, for example), but it is not widely used for desktop apps, even though it would be a good language for them.
It wasn't Debian's place to decide that maybe Ruby should work more like Python. Packaging, by the way, is a longstanding sore point with Python developers; RubyGems is one of the few clear wins Ruby had over Python.
Really? I haven't used RubyGems, but one of my favourite things about Python packaging is that I can take a proper Python distutils-based package, and in about thirty seconds create a usable RedHat package that my sysadmin colleagues can safely and easily deploy to our production systems, alongside all the other updates they manage.
I believe various Debian packaging "helper" scripts (like Joey Hess' "debhelper") have built-in support for Python distutils packages too.
Python's index is the equivalent of rubygems.org. "pip" / "easy_install" is the equivalent of the "gem" command. "virtualenv" is the equivalent of "rvm" (more or less, I prefer virtualenv), a gem in Python's world is a package containing a "distutils" specification.
The difference: python's index is more comprehensive and CPAN still beats both :)
And look where Python is on the various distributions. Behind. Constantly behind. The day a distro decides to use Ruby for system level stuff like they used python is the day that Ruby on that distro is DoA.
Of course it's behind, and that's what end users want. Bleeding edge is called that for a reason.
Python on Debian works fine. There are a whole bunch of apps written in old versions of Python that just work, and you never have to fiddle with dependencies, and you never break them.
If you want to develop in Python, you install virtualenv and you get a bleeding edge setup exactly like you want it, and it doesn't break your working apps.
The OS-packaged Python version is designed to support the OS-packaged Python applications. No more, no less. The whole point of having a software distribution is that it's curated such that it all works together. Your code? Not curated, so no guarantees. Module Y? Maybe curated, maybe not.
Getting "running code on the server" is an edge case, not the primary goal.
You say that as if that's a bad point: what's the point of being always on the bleeding edge for the end user ? What do you think is the work of a linux distribution (or any packager, really). I am quite proeficient in python (which has basically the same issue), and certainly can compile it by myself - but this takes time, knowledge, and is detrimental to the platform in the end if that's required. There is no hard issue that I cannot solve by myself, but OTOH, as soon as I want to share things with other people, this is nightmarish because of versions issues, incompatibilities, etc...
Lots of people use python but are not developers at core, and having constantly changing things every few months is horrible. Imagine what would happen if everybody was working the same way: gcc in debian would be optimized for gcc developers, so you are always on the bleeding edge, and if your program crashes because gcc had a bug or temporary incompatibiliy, no biggie, right ? Same for kernel, etc...
The kernel is actually a good example on how to do things: the kernel itself changes quickly, but distros do the work of stabilizing things.
I agree wholeheartedly. I develop in ruby and ocaml on ubuntu, which both suffer this problem (I assume all languages do).
As a user, I have no tolerance for dealing with dependency hell for things like a desktop pdf viewer or rss reader, and a decent gui frontend to APT literally provides a one-click solution to installing an application and all it's required dependencies.
As a developer, I gave up on using APT as part of my development process long ago - I manage my own library of sources and binaries. It's just too painful to synchronize a development environment with the debian/ubuntu repositories that are being updated on their own schedule.
From personal experience, I can say the worst case is having your development environment break b/c you updated your email client, which is easy to do if you use APT to manage your binaries, regardless of the languages involved.
I am not going to say that the current packaging scheme is ideal, but to say that Ruby shouldn't be packaged at all on systems like Debian and Redhat is to ignore a lot of the very real good that has come of quality package managers like dpkg/apt and rpm.
One use case would be if someone, say a sysadmin, wants a good bug tracking system for internal use at their company.
apt-get install redmine
Fetches Rails, Ruby and so on, and sets it up in a default, reasonably secure way (as far as I know, I haven't the Debian version myself).
That sort of thing is pretty commonplace with PHP web applications under Debian and Ubuntu. Granted, if you're going to hack on and modify the application in question, yeah, you may want to get it and install it yourself, but when things work well, a good packaging system lets you install and work with code that perhaps you do not know intimately.
I think you're making the mistake of viewing the world exclusively from the point of view of a Ruby developer. What would happen if you had to deal with different systems to install, maintain and upgrade the Linux kernel, Apache, Postgres, Sqlite, Ruby, GCC, Perl, Python, Gnome, and various submodules used by them? There are times when it's necessary to install your own version of something, but it's awfully, awfully nice that you can "choose your battles", and really only do that with stuff you care about and follow closely.
Sounds like Linux in the days when you installed Slackware and then just upgraded stuff by randomly recompiling bits and pieces every now and then.
BTW, I would hope that we could skip any "angry disagreements" here. Passion will do more than suffice!
I don't think that really makes sense. I think the sysadmin should instead have to do:
apt-get install rubygems
gem install redmine
I know it's two steps and they have to understand the dependency, but the truth is everyone in the Ruby world kind of assumes you're using Rubygems, and repackaging things from one packaging format to another just seems like it's asking for trouble.
Sysadmins can learn that if they want something from the ruby world they have to install rubygems.
* "Sysadmins can learn that if they want something from the Python world they have to install pip."
* "Sysadmins can learn that if they want something from the Lisp world they have to install clbuild."
* "Sysadmins can learn that if they want something from the Lua world they have to install luarocks."
* "Sysadmins can learn that if they want something from the PHP world they have to install PEAR."
* "Sysadmins can learn that if they want something from the Perl world they have to install CPAN."
* "Sysadmins can learn that if they want something from the Haskell world they have to install cabal."
* "Sysadmins can learn that if they want something from the O'Caml world they have to install godi."
Thank you. As a Ruby package developer, I have to care about MANY platforms, not just Debian.
This is why RubyGems was developed, because neither Windows nor Mac OS X have package managers built in. Debian maintainers may despise RubyGems and what it represents, but the RubyGems developers have never been unwilling to take patches that make them better citizens. They have not, however, been interested in neutering fundamental features.
That argument would make sense if RubyGems was actually useful on OS X or Windows. But every single application targeted at "normal users" on Windows or OSX written in Ruby bundles all dependencies, usually even including Ruby itself.
RubyGems needs to REMOVE harmful features, like the ability to install multiple minor versions of the same gem. Developers should be using RVM to get this capability.
The ability to install multiple versions of the same gem are pretty much key to the migration path of any ruby app. Just because it doesn't fit in the package manager world of some (read: all) distributions is not the fault of Ruby.
I can't count the number of times that we rolled out (while I was at the AJC) a new version of one of our apps on a different version of rails while keeping the other apps collocated on the same box running the previous version.
I developed PDF::Writer entirely on Windows and used RubyGems extensively. With the new Ruby Installer work by Luis Lavena and others, RubyGems is now amazingly awesome on Windows.
The Linuxes are the least-well represented and the least interested in working with RubyGems developers. There are hooks to make things work better: they were first offered by Apple and subsequently modified by Eric Hodel to be more generic so that Debian could benefit. They refused to use these vendor hooks.
You're right that apps that target "desktop" users bundle Ruby, but I remember a game from 2001 that bundled Python. This is no different. Apps need to control their dependencies (my company's backup app includes vendor-locked versions of OpenSSL in the program directory because we can't trust full compatibility without that)
Edited to add:
The RubyGems multiple version feature (which is one of the things that the Debian team seems to dislike) doesn't assign any meaning to version levels. The fact that 1.2.3 usually means "major version 1, minor version 2, patch version 3" is entirely social and of no meaning to RubyGems. The only thing that it cares about is that version A is comparably larger or smaller than version B. I could have version 1.2.3.4.5 and 1.3.5.7 and it would only care that the latter is larger (because the second level of the latter is larger than the second level of the former).
Removing this but keeping "top-level" versions would encourage people to rev their top-level versions more often. This may not be a bad thing, but it won't give you the effect you think it will.
Huh? OS X is my primary development platform, Debian is my primary deployment platform, and on both, I use a ruby from /usr/local/bin, and I type "bundle install" to get my deps working, and everything works fine.
But you're a web developer. Ruby works excellently for developers and for web apps.
Debian's primary concern is for end users, those who install applications via the pretty GUI. RubyGems made some choices that are very poor for these users.
The Ruby community has decided that these users are unimportant. And that's fair, there aren't many of them. "Fixing" RubyGems would not help developers, would not help web apps, would not help OS X or Windows end users, all of whom far outnumber Linux end users.
But recognize that this is a deliberate decision on the part of the Ruby community to ignore these users. But these Linux end users are Debian's raison d'etre, so recognize that the blame properly belongs on the shoulders of the Ruby community.
It may be a reasonable decision on the Ruby community's part, but it's still their "fault".
I take your point: Ruby has made decisions that make it hard to install end-user applications (what few there are) without bundling up an entire additional Ruby universe. Ruby - community - Ruby doesn't work for end-user applications that want to depend on a single system Ruby. Yes. This is true. I get it.
But the actions Debian took to try to fix that situation broke Ruby for Ruby's real users, which are developers. You say that nothing Debian could have done would change things for developers, but that's not true; you presume that, had Debian not undertaken it's strange neutering of RubyGems, Ruby devs would still have to rebuild the universe to deploy there. No. I don't do that on OS X. I only have to do it on Debian, because Debian was wrong about Ruby.
The statement "Ruby's real users" is telling. Ruby's real users include everyone downstream using Ruby applications: web apps, gems, tools, stand-alone apps. Some compromise needs to be made to suit all parties. Thus far it seems to me that the Debian world has been trying to make it work whilst a lot of Rubyists throw rocks from the sidelines. YMMV.
Yes, this is clearly what the Debian people think. But you aren't engaging with the argument, you're just hissing at it.
Again: I didn't just say "Ruby's real users are people who think like I do". I said "Ruby is used by significantly more developers than by end-users and should be optimized for its most important use case". You can disagree with that, but the onus is on your to support your argument with evidence.
Instead, you've attempted to personalize the argument. Try again.
This. From what I've seen of the entire Debian-Ruby fiasco, your post accurately describes how Debian people talk past all the people who are complaining about Ruby on Debian.
Ruby targets developers. I think that's wrong, but let's say you're right. It still doesn't matter. Debian targets end users. If you want a distribution that doesn't target end users, use a different distribution, like Gentoo.
But Debian is one of the best distributions because of the way it targets end users and because it never compromises.
The thing you're missing here is the privileged place "/usr/bin" has on the filesystem. It is reasonable and proper for a package to expect to install a real, unadulterated version of itself in the standard user path. You can't simply say "well, developers can just install their own version" while at the same time installing a broken version of Ruby in the standard path.
The right call would have been not to package Ruby at all.
I think it may even be true that distribution maintainers should look at installing the scripting languages their OS requires in different privileged places and version-locking their system scripts, as upgrading Python from 2.4 to 2.7 can break some system scripts, yet useful tools like Mercurial don't like very old versions of Python.
Au contraire: the Debian world has crippled RubyGems, which focusses on making Ruby packaging work everywhere, while Apple made modifications that made it work as Rubyists expect without causing problems for Apple's own needs. Eric Hodel modified this to make it easier for Linux distro maintainers to allow RubyGems to work as Rubyists expect yet not break the distro's expectations. The Debian maintainers chose not to adopt this. I don't use other distros, so I don't know whether they did or not.
What I've never personally understood is why the distro maintainers didn't embrace RubyGems. There's no reason that a .deb couldn't simply wrap a .gem and use the RubyGems infrastructure to install it into a "protected" area (preventing 'gem remove' from working, per the modifications noted above). A .gem can even be a repackaged version that includes platform-specific compiled code so that it could be distributed to machines without compilers (this is one thing that could be improved for RubyGems; allowing users to gemify a built gem for deployment purposes). I've suggested this in the past and it's been met with derision from OS maintainers. I don't understand why: as I understand it, this is what happens with BSD ports of gems.
So no, the Ruby community hasn't thrown rocks from the sidelines. We've made constructive suggestions that have been derided or ignored; so ignored, we've made our own solutions that work well for our needs.
Some of the problems that Debian has had have been simply due to lack of manpower. AFAICT, they could have made `gem update --system` work, but that would have taken a lot of time they didn't have, so they disabled it.
And it's a thankless task. There's no way that Debian would ever compromise on anything, the Ruby community is not interested in removing features from RubyGems to accomodate Debian, and the developers are caught in the middle, being blamed for problems caused by policies they have no control over.
So of course, nobody wants to volunteer to help.
That's why when they get attacked (like I saw you doing), I jump in to defend them.
There is hope for the future -- Bundler and RVM make many of the "features" of RubyGems obsolete, IMO.
But I still disagree with your statement that Ruby's real users are developers. End users are the whole point of developers. Without end users, developers are just masturbating. It's fun, but it doesn't get anywhere.
> There is hope for the future -- Bundler and RVM make many of the "features" of RubyGems obsolete, IMO.
What? Bundler uses RubyGems! Why do you think Gemfile is called Gemfile?
I think we're talking about two different aspects of RubyGems here:
1. The "gem install" command.
2. The RubyGems database and gem activation code.
Bundler merely replaces the first part. It uses the second part at its core. Still, it makes no sense to me that you see Bundler as "hope". It installs the same gems, just to different places now, usually project-dependent spaces. This latter results in duplication and I thought that was one of the things that Debian people despise.
> But I still disagree with your statement that Ruby's real users are developers. End users are the whole point of developers. Without end users, developers are just masturbating. It's fun, but it doesn't get anywhere.
The end users are the people using the web apps. And they don't install anything.
Even if we define "end users" as "people using Ruby apps", or to take a concrete example, "Redmine users", Debian's current packaging is still next to useless. It forces users to install their own Ruby from source just to make any modern Ruby app working.
So I am going to suggest you're a developer. I am, amongst other things, a packager. Lots of platforme mandate that certain types of binaries go in certain places. This isntpossible with gems. I find this very frustrating for the gems I maintain - including Puppet for example.
If FHS religion means you can't put something in bin(7) if it's an admin-only tool, and the author of that tool built it in a way that only allows it to be installed in bin(7) and not sbin(7), then don't package the tool. The "alter the tool so it fits with our doctrines" approach hasn't worked.
Again, this isn't Ruby saying "Jeb's network configuration script must go in bin(7) even though he wants it to go in sbin(7)". This is "every Ruby developer writes tools that go in some variant of bin(7)", and Debian not liking that.
Which, fine. Don't like it. Just don't package them.
Don't package them isn't a solution. It's sticking your head in the sand.
Again and again in the Ruby world I see the "it works for us web developers on the x number of hosts we run". The people who use Ruby for stand-alone applications across multiple hosts are largely ignored.
I'd love to see more Ruby out there - ignoring the needs of people other than developers guarantees that'll never happen. Big shops and sys admins who run non-web applications (and even those who run Ruby/Rails web applications and find the RubyGems/Passenger/Rails/Ruby/etc/etc intra/inter version interoperability failures baffling) will look at it as a manual, difficult to package solution and find other tools written in other languages.
/bin system binaries for all users
/sbin system binaries for root
/usr/bin distro binaries for all users
/usr/sbin distro binaries for root
/usr/local/bin binaries managed by repository, but not by distro for all users
/usr/local/sbin binaries managed by repository, but not by distro for all root
/opt/bin/ user compiled and installed binaries for all users
/opt/sbin/ root compiled and installed binaries for root purposes
more or less? I would expect GEMs to follow behaviour?
Gratuitous differences between Debian and the upstream installation layout are REALLY ANNOYING. It breaks all sorts of online documentation and means Debian users have to deal with unnecessary compatibility bugs.
Is there any reason why you care so much about bin-vs-sbin that would make it such a dealbreaker, other than FHS ideology? Most people I know just care whether the command works, i.e. whether it's in $PATH.
They care that a specific random Ruby utility was by design installed in bin(7) and thus require that Debian specifically modifies the package so that it goes in sbin(7)? I call shenanigans.
I think the idea is that on every OS you talk the talk. Windows uses backslashes instead of slashes. etc. You meld application to OS, not the other way around.
GEMs on Debian should follow Debian ideology, much like on windows they follow windows way.
I repeat: "…the RubyGems developers have never been unwilling to take patches that make them better citizens."
Code talks. Provide a patch and I'm sure they'll take it, because it's a good step forward. If you do make such a patch, you'll need to consider what should happen if the user is running "gem install" without appropriate privileges or if the user is running on a system where there's no bin/ or sbin/ differentiation (e.g., Windows).
Um, you're joking, right? Perlbrew itself is fine (I use and like it - I actually wrote a small Bash completion script for it[2]), but it implements only a fraction of the functionality of rvm[1]. (Rvm also precedes Perlbrew by some time, I think).
I really hate to see Lucas burn out and I think the Ruby & Debian communities will both be negatively affected. I'm a Debian Ruby user whose contributed a tiny bit (first Redmine package) and I have watched Lucas and the rest of the team repeatedly bang their heads into a wall when trying to get agreement on something from either side.
My personal view is that the Ruby/GEM packages should be laid out like the Perl/CPAN, which seems to be doing just fine.
I like cpanm[1] quite a lot. Have you tried it as an alternative installer for modules? (I'm no Perl god, but I still maintain a healthy chunk of Perl code I wrote for sysadmin things a few years ago. I find that cpanm does exactly what I need it to, without the overhead of CPAN.)
How many other free software projects are significantly hindered by the language used by the main developers? I found that the most fascinating aspect of this post. Software tends to be so very English-centric that the fact that Ruby is Japanese really stands out.
I'm not sure software is "english-centric" so much as english being the linga franca of computing, much like diplomacy used to be mostly (if not solely) in french. You need a common language to share, and english was as good as any (better, in fact, since most early research [Church, Turing, Von Neumann, McCarthy] in CS was in english as were pretty much all the early implementations (Colossus, ENIAC, FORTRAN, ALGOL, BASIC, …)
> I'm not sure software is "english-centric" so much as english being the linga franca of computing, much like diplomacy used to be mostly (if not solely) in french.
At the very least: Diplomatic phrasing. But diplomacy is important. If I'm going to be audacious enough to ask the majority of the human race to conduct their business in my native language I can damn well try to be excessively polite about it.
But it does go beyond that. "English-centric software" could be interpreted as "software designed primarily by and for English speakers". And we wouldn't want to advocate that, because that has historically been a problem. Before Unicode, software supported English character sets much better than foreign-language character sets (and Western Europe better than Eastern Europe, and Europe better than Asia...). Even now, a lot of software doesn't support right-to-left languages. This kind of English-centrism is not good. We don't want to perpetuate it.
What the OP is advocating is "English as a lingua franca of software engineering", which is in fact a different thing.
For the record, the original poster's native language is French (and he even makes some English grammar mistakes if you pay attention, so I doubt that he learned English so long ago that using it is entirely simple for him).
> But it does go beyond that. "English-centric software" could be interpreted as "software designed primarily by and for English speakers".
Exactly, that's how I interpreted it (and thought others might interpret it as), and I completely disagree with it (though many softs are indeed english-centric I don't believe software as a field is).
That's of course all very true, but not very pertinent, as Ruby's support for convenient Japanese encodings was, for the longest time, as broken as all its haracter set and character encoding support. Ruby has never been a language for developing in Japanese or for developing for the
Japanese.
That's pretty much my point: the "A" in "ASCII" stands for "American", and software as a culture has remained plagued and characterized by that ever since. What I found remarkable about this post is that Ruby's development culture is distinctly not run in English, and it's creating the predictable amount of friction.
The Japanese are no less insular than Americans when it comes to actual belief in the independent existence of anything off their shores - I find it fascinating to see that reflected in the Ruby project.
I believe that early on most of the OCaml community was French-speaking.
Personally, I found that aspect of the article borderline offensive. Oh, people shouldn't speak their native language because... speak English dammit! Oh, and don't release software on Dec 25th. (News flash: the majority of the world population does not celebrate Christmas.)
I think it's a problem when your project goes international. You have to choose a language to communicate with the larger community.
Some countries do not have this problem, the Anglo-Saxon world can communicate with a common language, they are inflated by the Indian community that generally uses English in their communication as well.
India, with its many official languages, is a living example of how this can be a problem in Science and Technical communities, restricting our problem to programming you'll hardly see an Indian developer starting a project and documenting it in Marathi, Hindi, Urdu, Tamil or Malayalam (or others with more than 10 million speakers).
This can be a problem, so you have to decide very early how you'll approach this problem, Linus Torvalds for example chose English in the beginning instead of his native Swedish. The Lua developers chose a similar route, since they native language is Portuguese, I do not know much about Python, but I expect that Guido also chose English to communicate with developers instead of Dutch. Ruby apparently took another way, some people sees this as a problem, others don't, personally I would not like to work in a project in which I cannot ask some guys directly because we do not know a common language to communicate.
For me English is a easy choice since the majority of people learn some English in school or college, or even playing games.
Oh, people shouldn't speak their native language because... speak English dammit!
Nothing offensive about that, as long as it's expressed in a polite manner. To me it sounds like a constructive proposal from someone who has witnessed the problems first-hand, he's not just "ranting from the sidelines".
This is not about imperialism. It's about improving the communications in a project that has long turned international. English is the lowest common denominator. Refusing to acknowledge that simple fact does not help anything.
A majority does not celebrate Christmas, but a large chunk of it does. Even if you don't celebrate Christmas, you may have time off of work anyways. It's just not a good time to do the yearly release in my opinion (and the author's too)
This reflects a larger issue about project management: Do you want more people working a little on the project or a few top performers working at their absolute maximum productivity? If I was them I'd keep running the project in the way that makes the top 10 contributors as productive as possible, and it sounds like keeping the discussions in Japanese is the way to go.
Think about if we were discussing Apple. Would you really suggest it would be worth making the top performers (including Steve Jobs) do their day to day work in Japanese if it meant more people could participate in the discussions? Or do you want to do everything you can to have the people who really know what they're doing working at their optimum?
It could well be a 'local optimum' - switching to English would slow things down for a bit, until the much larger pool of people who speak some English started to get involved, and a few to stand out, and take things to a level the smaller group could never have reached.
I started using RVM a little while ago, and... I am not that excited about it (although it is well done and mostly works as advertised). It seems like the direction Ruby is going is to have things like Rails applications that require their own version of Ruby and a whole slew of gems, which also means that if you have a number of applications, you start getting a large amount of duplication? I'm not entirely sure as I'm new to the system, but it adds an extra level of installed stuff that I'm not 100% comfortable with.
Edit: as an aside, Zed Shaw's wild attacks and untruthful accusations against Debian were some ugliness that the world could have done without. I hope Lucas finds other places to more productively (and happily) employ his talents in the free software world.
A) Duplicate code sucks up storage space, and bandwidth to transfer it around. There was a time, in living memory, when this argument was strong. But it became moot several years ago when they started giving away free encyclopedias in my breakfast cereal.
B) Duplicate code sucks up memory in running processes. This argument is still potentially strong, but without getting into the important Ruby-centric details (Can separate processes usefully share Ruby code anyway? What are the mechanisms for that? Do people really often run more than, say, two Ruby interpreter codebases on any given machine?) let's just point out that this is premature optimization -- especially in 2011, when RAM is cheap, boxes are cheap, everything is virtualized, and you should probably be running every application in its own virtual server anyway.
In the general case, it is more important that code be simple to install, correct, and reliable than that it have a light memory footprint. If you are smart enough and motivated enough to understand the need to optimize your software you have the tools to do so.
C) Duplicate code creates management headaches. You think you've updated the gem, but you've really only done so in one place. You forgot the other six places.
This is a real concern, but RVM plus Bundler represents an improvement, not a regression. For one thing: Before RVM there were several incidents where I battled the infamous `gem install` vs `sudo gem install` dichotomy. That problem -- getting every app and library to load the right library path without using RVM -- is an order of magnitude more confusing than anything in RVM.
I agree completely with A for most things outside of embedded systems, and even those are generally getting more and more space, and Ruby isn't really ideal for that anyway.
I disagree with B somewhat. I currently have a machine running about a dozen different Rails applications with no problems at all. I am indeed unhappy with the fact that Ruby does not share code better, because I could either save money on monthly costs or add more applications (I do know about "Enterprise" Ruby but prefer to stick with the system version). And yes, memory is cheap, but costs do multiply when you have to pay for extra ram every month (ala Linode). I also don't want or need the overhead for separate virtual servers for each and every application I happen to write unless they get big.
However, yes, C) is really the main concern. And I've found that just using system (root) level gems is the best way of keeping everything sane. I don't install per-user gems. So for me RVM/Bundler represents a real extra step and more things to know about than just gems by itself.
In the end, I use Ruby a lot these days, so I'm not unhappy with RVM. It's well done, and generally a good thing. I guess I just don't like the direction it seems to represent: packaging each thing in its own world. I prefer a shared world with divergences only where they are required.
What's the extra step to know with Bundler? I learned it in --- not exaggerating --- under 5 minutes. It took longer to run than to learn.
Now, instead of typing looking up the list of gems I need to install and then typing a bunch of gem commands, I copy my skeleton Rails Gemfile (which is literally just a list of gems with "get them from gemcutter" at the top), type "bundle install bundle", and I'm absolutely done.
You seem to be dodging 'mechanical_fish's point: Bundler improves the process. It isn't "more"; it's "better". They should have just called it Gem 2.0.
For the most part, I don't mind bundler, but I think it's too early to say it's overwhelmingly and only an improvement.
I can think of two cases where it concerns me:
1) I'm now supposed to type, for example, `bundle exec spork` instead of simply `spork`. This is extra typing, an extra thing for me to remember and it causes binaries to load/launch/start more slowly. (Yes, I've timed it.)
2) Bundler seems to break things in odd, hard to debug ways. I hang out a reasonable amount in #rvm on Freenode, and not an hour goes by that someone doesn't come in with a complex, hard-to-solve issue involving rvm, bundler, $LOAD_PATH and I don't know what else.
I admit that (1) is maybe somewhat petty, and (2) is probably not all bundler's fault. Still, I continue to have very mixed feelings about bundler. (My current compromise is that I only use it for Rails apps.)
Bundler is designed for its primary use case: web apps.
(1) is acceptable for web apps because they need to start once and stay alive until the next redeploy. Granted, the starting time is pretty stupid for desktop apps and even command line apps like the RSpec runner, but as people have already mentioned web app developers who deploy on Debian are the biggest part of the Debian Ruby userbase.
(2) shouldn't ever happen. Bundler is designed exactly to avoid inconsistent breakages, e.g. breakages that happen in production but not development. Bundler guarantees that things fail in the same way in any environment. If something fails then that means you're missing an entry in your Gemfile. I'd like to have a look at your problem.
(2) wasn't my problem; it's problems I've seen (repeatedly) in irc, as I said. For some (random) examples of people with issues related to bundler (ghost gems, gems that can't be found though bundler itself installed them), see the last handful of posts on this thread: http://yehudakatz.com/2010/09/30/bundler-as-simple-as-what-y...
As for the primary use case being web apps, I suppose that makes sense, except... Except that the Ruby community (or large parts of it, at least) are now suggesting that all Ruby development be done using bundler. And bundler itself also includes a jeweler-like/hoe-like tool to jump-start new gems.
I don't want to overdo it: I don't vehemently object to bundler, but it's size, dependency chain, strong opinions and (to me at least) apparent desire to take over the gem ecosystem make me a little worried.
> Except that the Ruby community (or large parts of it, at least) are now suggesting that all Ruby development be done using bundler.
I don't agree with that either. I think that there are legit as well as illegitimate use cases and that people don't always understand which is which. That said, I don't think it's any reason to dismiss Bundler.
I believe the core of Bundler - the multiple gem activation algorithm - should be part of RubyGems itself. If that is part of RubyGems then it would take away the need to use Bundler for many non-web app projects.
With Bundler you do have duplication most of the time. Bundler installs the gems to ./help by default so you get your own gem directory for every project.
> Requiring an exact version of Ruby for a project is a practice that avoids rare issues of version inconsistency.
If they're rare, you ought to identify them, and, rather than require an exact version, say "this version or greater", and spell out exactly why in the comments, so that future users of your code will know precisely what code is affected and be able to reason about it themselves.
A version requirement is a statement that "I have tested this code with these versions of the dependencies and verified that it works." Yes, given sufficient time and energy one can also test the code against many older versions of the dependencies, find any bugs, and include explanatory comments, as you suggest. But one can't test against the dependencies as they will exist in the future.
> That only works if all future versions are guaranteed to be backwards-compatible with the current version. A guarantee that does not exist.
It's not the sort of thing that's easy to prove empirically one way or the other, but I get the feeling (despite being a heavy user and fan of Ruby) that other languages take that guarantee more seriously. It's a tradeoff: by not spending much effort on backwards compatibility, they can spend more time developing "cool new stuff". Users get more new stuff faster, at the expense of having to worry more about upgrades breaking things.
> It's not the sort of thing that's easy to prove empirically one way or the other
On the contrary. People on real production environments encounter the lack of compatibility guarantee all the time. Bundler is a way to guarantee compatibility regardless of actual future release compatibility.
> other languages take that guarantee more seriously
In general this seems to be true, but they do so on a best-effort basis. None of them provide perfect guarantee; that is, if there's some kind of law that would allow you to sue them $1000000 every time they break compatibility you would be VERY rich by now.
For example many people who use Python in production environments use virtualenv to guarantee compatibility. Virtualenv has a similar function to Bundler. Java people just tend to vendor specific versions of dependencies and don't rely on shared dependencies at all.
Even high-profile libraries that have extremely well-defined compatibility guarantees - such as GTK - tend to mess up from time to time. A few years ago they made a change in GObject. If you upgraded GTK then that would break the GNOME login manager, rendering your desktop useless (this problem was later fixed).
Breaking compatibility because of human error happens all the time, and often in unexpected ways. Bundler and similar tools provide protection against that in return for a bunch of other disadvantages. The point is you can't see compatibility as an either-perfect-or-nonexistant thing.
other languages take that guarantee more seriously
It's more than just a feeling. They certainly do.
But: Those languages are there. They live! Perl 5, for example, is there. It has not gone anywhere. Its community would love for you to use it. The fact that some people sometimes decide to use other things tells us something about the value of backwards compatibility in uncertain times.
My impression is that Ruby does change uncomfortably quickly, but not so quickly as its problem domains are changing. The rate of change of our software ecosystems is a symptom, not a cause. My god, the things that have happened in the last decade. Cheap virtual machines in the cloud. Widespread use of distributed version control. Client-side web apps. Mobile applications. NeXT cubes in your pocket for $250.
> The fact that some people sometimes decide to use other things tells us something about the value of backwards compatibility in uncertain times.
Java, which seems to take it fairly seriously, is way more popular than Ruby is.
I agree that the world changes quickly, but disagree that you need to radically change stuff all the time.
For instance, in Rails, they went from <%= to <% back to <%= for forms. To me as an end user, that is completely useless churn.
Like I've said, I like Ruby and am mostly happy with it, but there's a tendency to rush off after the 'latest new thing!' that at times I view as counterproductive.
You're kidding me, Java? We're talking about compatibility in the context of avoiding code duplication. Java itself is very good at compatibility but compatibility of third party libraries are wildly different, plus Java apps tend to vendor all third party libraries regardless of compatibility guarantees.
As for the Rails <%= thing, where did you get the idea from that they went from <%= to <% and back to <%=? Did all of this happen within the same release minor release cycle? Rails has a strong compatibility policy for minor releases and only tend to break things between different minor releases.
Are you seriously complaining about a compatibility breakage that conforms to their compatibility policy? You knew exactly what kind of guarantees you signed up for. You can't expect developers to never break anything unless you don't want any form of innovation. And as far as I know the old <% form_for %> still works! You don't have to use <%=.
> Are you seriously complaining about a compatibility breakage that conforms to their compatibility policy?
Yes, I am. Just because they have a policy in place doesn't mean that I lose my right to air my opinions.
The point with the <% thing is that it feels a bit too much like gratuitous code churn to me. <%= is what you use to output something, and you do want to output a form, so <%= is what they should have stuck with from the beginning.
The inability to use <%= for form_for was a limitation in ERB. Using <%= for form_for to make things consistent is a new feature since Rails 3. This has got nothing to do with compatibility.
This might be true, but it does depend on how the release management is done. What else is part of that new release? Is it guaranteed to be a set of minimalist patches to fix security issues, or do the developers also take the opportunity to "tidy up" the API, or take out some of those "deprecated" features, or (god help us) introduce new functionality? [1]
Much of what we see here is a dev/ops culture clash. Sysadmins like well-established system-level packaging systems like .deb and .rpm. They like them because they have well-established semantics ("this thing is obviously a security patch; that thing is probably a feature upgrade"), and they like them because these systems abstract away the need for the admin to understand the details of the release model of five or ten or a hundred different open-source ecosystems.
Part of OP's complaint is that (from his perspective) the Ruby community has release semantics that he doesn't understand. Is that patch to Ruby 1.8.7 really just a "security fix"? Can it probably be safely applied to 1,000 production servers without causing downtime?
---
[1] I should note: I'm not accusing Ruby developers, or any other developers, of ever having done any of these things. But these are the dark thoughts that keep engineers up at night. Especially when managing codebases built on ecosystems that they don't intimately understand.
It's yet another way of installing software on my system. Currently I:
* Use apt-get for pretty much everything.
* Locally install a few project specific things. These often are installed locally, not system-wide, and have nothing to do with root.
* Use rubygems. It's nice, but I don't have the same level of confidence in it regarding security that I do about Debian and Ubuntu. It seems to just give me 'updates' to gems, without much of a way of knowing which updates are security fixes and which are simply improved versions of the packages in question.
RVM adds one more thing. And for each Ruby instance in there, I might have various versions of gems floating around. This does not make me happy from a security point of view.
With one command, apt-get, I can use the same command line to install security updates for the Ubuntu versions of Ruby, Python, Java, Lua, Perl, Tcl, PHP, Erlang, Haskell, Ocaml and whatever else I happen to use. If you have to learn a separate "pretty easy" command to get security updates for the various systems on your computer, you are screwed. I think having one or two extra routes for systems that you use heavily (you're a Ruby dev or a Java dev or something like that) is probably ok, but it's still nothing I'm thrilled about.
but then your stuck using whatever version of ruby your distro is own. If your core development is ruby, I wouldn't leave that decision to someone else.
Actually, it's generally not that hard to take an existing Debian package and update it to the latest version of whatever software you're dealing with, if you absolutely must run a particular version.
Also, Debian takes a lot of efforts to make different major versions run in parallel, like Ruby 1.8 and 1.9, Tcl 8.4 and 8.5 and so on.
One of the points of RVM is to allow different versions of Ruby to be installed side-by-side easily...
Also, large packages like Ruby often have a boat-load of customizations and patches applied to them that may not apply cleanly to subsequent releases of that software. Modifying a debian package to build a new version is significantly more nightmarish than the RVM install process.
Yes, once you've gone off and created your own package, you're off the upgrade train, and so it's something you ought to take very seriously.
rvm is easier than doing your own packages, certainly, but imagine if you had to use an 'easy', but different tool for everything on your systems.
Also, 'easy' it may be, but I'm not convinced of how things will work out in terms of security, whereas I have a lot of trust in Debian and Ubuntu's security teams. Time will tell, I suppose.
I think the thing here is just a perspective issue. If your focus is the tool, then you want platform agnostic. If your focus is the platform, then you want tool agnostic.
For example, if I'm a ruby developer that ends up using different platforms often (osx, debian, centos) then it's justifiable that I want to use a packaging abstraction that's platform agnostic but ruby specific.
If I'm a primarily a debian user that happens to program in ruby and a dozen other languages then I would prefer a packaging abstraction that's tool agnostic but debian specific.
exactly, you don't want to do them all with a different "easy" tool. For me, I use ruby and rails for sites, and ruby for scripting everything. Basically, ruby is my core tool. I manage my entire system with apt-get except for ruby, where I use rvm. It's worked really well for me.
Or, at work it's basically the same thing but with java and maven to manage java stuff. Java's had a similar history of butting heads with package management systems.
RVM is great for some things and a bane for others. Like you, I use it all day, every day to build & test multiple Ruby projects on my MacBook. It has really increased my output and reduced my hair-pulling.
On the other hand, automating and managing a server install using RVM is a nightmare. I don't want/need compilers on my servers, I just want to push a package out and have it work (i.e. APT).
out of curiosity, what other issues does RVM pose to "others", other than having to apt-get install compilers?
also, wouldn't you need compilers anyway, for a whole lot of gems that use native extensions?
No, that is the beauty of using system packages, you just apt-get install them (if they are packaged, that is). That is why it is so important for projects to make it easy for distributions to (re)package extensions.
At RubyKaigi, we talked about closing the Japanese list. It's a bad idea because closing the list will not stop conversations from happening in Japanese, it will just move the conversations to IRC. At least, if we have the conversations recorded, there is an opportunity to translate them.
I just know that whenever I wanted to use the official ubuntu repository, I ended up not being able to install a gem because rubygems was too old. Since gem update --system doesn't seem to work on debian-based systems, I just had to install it from source again
This wasn't a problem for a long time, but then a major release of release of rubygems came out, and then the switch to gemcutter happened, etc. I've gotten around this by installing everything but rubygems from the regular Ruby packages from the Debian (or ubuntu) repos. I install the rubygems.org version of rubygems and everything works great.
I understand Lucas' decision, however it leaves some worrying questions about the state of ruby on Debian systems.
Despite the rumours, the ruby1.8, ruby1.9 and rubygems packages are are excellent shape thanks to the hard work by Lucas, Diago and Akira.
There were consistent fundamental workflow clashes between upstream and the Debian packagers that have made their job exceedingly difficult. These clashes aren't malicious or antagonistic, they're just the meeting of two very different communities with very different priorities.
To name a few of the clashes: API changes in minor releases, effective forking of rubygems by copying it into the 1.9 tree, opaque decision making (mostly due to the language barrier), allowing installed programs (ie rubygems) to update themselves and expectations on what is allowed in /usr/bin.
I'm not saying either community is necessarily correct on these issues, just that they add up to some pretty big differences for debian-ruby to navigate.
I use the Debian packages for ruby1.8, 1.9.2, jruby and rubygems in both my development and production environments. I've found them stable, rapidly updated in response to security issues and predictable. Lucas - thanks for your efforts, they will be missed.
A similar situation exists in Lisp. Most everyone I know downloads the lisp of their choice (SBCL, CCL, Clojure) from the project site and goes forward from there.
This seems particularly true of efforts that are cross-platform. In particular, developing for Linux and Mac pretty much makes this the way to go for these two languages.
Has anyone considered that crap like RubyGems, RVM, and Bundler is a symptom of us as rapid (read: careless) developers not being able to manage our code and our releases in an organized and well-ordered manner, not a symptom of poor package management by distributions?
The same thing happened to Gentoo. I talked to the people behind Ruby packages in Gentoo and they wanted to manually create packages for each gem. It is one of the main reasons why I gave up on Gentoo and went back to Arch Linux.
I see gems as just snippets of code instead of "real" OS packages. They change a lot, they are application specific, and (most of the time) they are simple.
> I see gems as just snippets of code instead of "real" OS packages. They change a lot, they are application specific, and (most of the time) they are simple.
And, like me, if you're using Rails, they are code that is visible to the outside world. That is code that you want to make sure is secure, and is not just some minor detail.
People - you forget that the Debian community is not just random packagers but also developers. Debian packagers try VERY hard indeed to produce a stable system that works out of the box for all of their users - and that includes developers of all sorts with all types of development environment for several common programming languages.
As part of that, it's useful to know what's stable and what isn't. Debian tends to track version numbers and look for stable versions for a reason - once released, Debian commits to supporting a release for the lifetime of that release plus one year - roughly three years now. Anything that isn't actually released as stable and thereby fixed will go into testing/unstable - there's nothing to stop you running the latest and greatest at any time, but possibly not on Debian stable.
In another life, I have to deal with developers who say to me: just mirror Ruby and Rails for us on the inside of the corporate firewall. There isn't an easy place to start - if you want to build a Ruby infrastructure inside a large company, with software management systems, management suspicion of FLOSS but committed developers - where do you begin to convince people that this is a usable infrastructure?
Red Hat support a subset of very common packages and will support these now for up to 10 years. That's your banks, stock exchanges, infrastructure companies: if you want Ruby developers and programmers to make inroads into that sort of environment, then you need sane packaging sense or at least a sense of what's usable.
Debian produces a far larger subset for use of the programs out there - and on 13 hardware architectures.
As regards the English/Japanese language flaming: Debian has 1000 or so developers and maintainers, spread worldwide - Lucas is a French speaker, originally, but Debian developers speak and use most common human languages - English is a convenience to a truly distributed, international community.
What would be nice is if RVM allowed a package option for an installed Ruby + gemset. RVM doesn't work for me on my servers because it break idemopotence but I'd love to install RVM on a testbed, type 'rvm package' and get a tarball that I can dump in /opt/ on my production systems.
I've never had very good luck using the Ubuntu Ruby packages. The binaries are never linked, and I can't update Rubygems, which means I can't install a lot of gems that I need. Is it tough to use RVM on a production server? Is it easy to get Thin setup and all that?
So what is it that RubyGems does differently than other languages that makes it so hard to support? Having a binary debian package for each ruby distro makes sense (as an alternative to rvm), but I'm not really sure why gem is a hindrance.
I wondered about this myself as I wrote, but I wasn't 100% sure that CPAN could self-update. I don't honestly know why they're treated differently. (I also wonder about cabal and pip and luarocks, etc. I just don't know.)
Corrado mentions here that he would like to see Ruby/gems handled more like Perl/CPAN in Debian, but I'm not sure exactly what that means or what it would look like.
I read through all the comments to make sure no one else has responded. I'm more of a Perl developer then a Ruby developer, but these are my observations of the differences between the two.
1. Perl Versioning is more thought out. It tends to have more consistent versioning semantics. Experimental branches are done in odd minor versions. e.g. 5.11.x was the development version; where 5.12.x is the stable release. All further development occurs on 5.13.x, etc. Patch level changes on the stable version are for minor updates (that don't break compatibility) or security fixes. Major changes to the language that break things are enabled by explicate pragams. E.G. use 5.10; Major version numbers represent core changes to the language, and really represent a new language, that may or may not be compatible with the previous language. E.G. Perl 5.X.x V.S. Perl 6.X.x. This adherence to the value of having development and release versions trickles down to the modules themselves.
2. CPAN is both a tool and the Archive.
a. As a tool it is great for both developers and package maintainers.
i. For developers:
* it allow them to install bleeding edge modules.
* easily upgrade those modules
ii. For maintainers it allows them to:
* query the Archive for various meta information (dependences {build, release}, author, license, etc)
* download the modules and extract them
* allow the creation of build tools (e.g. dh-make-perl,pbuilder) that automate the packaging of the module
b. As an Archive, it provides a common place with an agreed upon standard.
i. Modules on CPAN can be marked as a Developer release.
ii. Modules on CPAN can also be marked as released version.
iii. All information in the Archive can be Queried by the CPAN module, that is part of Perl CORE
iv. Perl Core, the interpreter and build tools are well defined.
v. Core modules are also well defined, and do not change at patch levels.
So, package maintainers can easily package perl modules into their os specific packaging system.
To make a Debian package on Lenny from CPAN it's as simple as: dh-make-perl --requiredeps --cpan Module::In::CPAN --build
If all your dependences are already in the system this will generate a deb for you, if not it will tell you the modules it could not find; so you can build them.
Perl modules allow you change where things are installed by respecting the various PREFIX config options. From what I have read here, it seems this is not true of RubyGems.
I don't know enough about RubyGems to know if it does the additional things the CPAN tools does. But the main thing is Perl/CPAN works with Debian by following their rules, and making it easy for them to build deb packages.
Whoa... Even though the developers of Ruby are Japanese, he's demanding that they start speaking fluent English instead? And he thinks others are being assholes?
Granted, he only said 'English' in his rant, but if it's typical Japanese English then he won't understand it half the time anyhow, so it'd have to be fluent English.
Here's a novel idea: FORK IT. If you don't like how a project is being run, that's your option. Telling others how to do their work doesn't work with open source. They don't have to listen to you, and calling them assholes certainly doesn't help.
Telling someone to FORK IT is only useful if the maintainers are so incredibly incompetent or toxic that even accepting the massive penalties of a fork (especially massive for huge commercially popular projects) one is better off with the fork.
Nowhere else. I don't want to live in a world where this is considered an acceptable response to every small and big criticism or suggestion for improvement:
"Hey, maybe we should remove that dead code."
"IF YOU DON'T LIKE DEAD CODE, FORK IT!"
"Have we considered moving to Git from our crufty old CVS?"
"IF YOU DON'T LIKE CVS UP, FORK IT!"
"Docbook really isn't very easy to contribute doc fixes to; I was thinking about rewriting our manual in Markdown since it's really not that complex a document - "
For at least a year now, I've simply accepted that Debian's Ruby lives in a parallel bizarro-universe, rm'd any trace of it that intrudes on my own (real) universe, and installed everything from source.
I write this not to feel better about myself but to attract the passionate, angry disagreements that will help me better understand the problems this guy was trying to solve, so I can understand how he looks at the world and what his decision means instead of silently hoping that this post means nobody is going to try to integrate Debian and Ruby anymore.