It removes the question of version management altogether by isolating an app's environment. Not too shabby an idea, especially now that Vagrant is available.
I actually think that the "RVM vs. rbenv vs. chruby" section of the BountySource page is pretty bad. There's almost no argument there, just that there are certain scenarios in which RVM "does a lot more to make handling [them] easy". What scenarios? In what situations would a "complex environment" or set of dependencies make RVM a choice that I'd "be a fool to not go with"? My experiences has been that a complicated tool like RVM makes for a _more_ environment, not one that's easier to work with.
Additionally, some of the schedule on that BountySource campaign makes me especially wary. If most of the code is rewritten in Ruby, presumably it would need to build/install Ruby during its own installation so it can be used afterwards. If the GUI relies on JRuby, it would need to build that during installation as well. Suddenly RVM becomes less easy to install.
The bootstrap for RVM 2.0 is something we're thinking about very seriously, to make sure it's handled properly and isn't brittle. As an rvm maintainer, one of the most frustrating things about working on it is how untestable and how brittle the installation (rvm + all build deps required to get a ruby built locally) can be.
It's a known problem and one of the current big design issues, especially because rvm is so complex today in what it's capable of on the user's behalf, so we plan to get that right first time as much as we can.
I agree with you on both of your points: the BountySource page is a bit hand wavy, although there's only so much room to spell out what we think our benefits are; that rvm can make life more complicated, not simpler.
I come to the project late in its life and I'm well aware it's a bit of a beast in many ways, so I can at least say that I'll be pushing Michal towards simplicity. It's one of the reasons 2.0 exists, rather than us heading towards 1.3 instead. It's just too hard to make large changes to 1.2 now, mostly because of the complexity inherent to being a shell program that works (mostly!) portably on the myriad OSes we now support.
For those curious, what that page by rvm authors suggests is that:
> Tools like rbenv or chruby can work well in simple scenarios, especially if you’re very skilled with the Unix shell. However, as environments and dependencies grow in complexity, these tools quickly become inadequate. RVM seems more “complicated” because it does a lot more to make handling these scenarios easy.
> To paraphrase Jonathan Jackson, RVM is to Rails as rbenv is to Sinatra. Sinatra is a lightweight framework whereas Rails is much more robust. Sometimes Sinatra just fits, and other times you'd be a fool to not go with Rails.
I think people with complicated scenarios have had... mixed experiences with whether rvm really makes complex scenarios easy. I suspect many people with complex scenarios prefer a simple tool like rbenv or chruby (disclosure: I prefer chruby having worked with all three), which they can then figure out themselves how to invoke to do exactly what they need.
It may be that some people with complex scenarios prefer rvm. It would be interesting to hear from them. (for real! I'd be interested!)
But I suspect that the bulk of rvm users are not actually sophisticated users with complicated scenarios, but instead beginner users with fairly simple scenarios. For a variety of reasons. Becuase rvm is what you find when you google. Because rvm holds out the promise of not making you understand anything about what it's doing or anything about bash or shell environment, and having it Just Work (whether it fulfills that promise... especially in non-simple scenarios... there are mixed opinions. There are definitely some people who have moved from rvm to rbenv or chruby in fact as their environments have grown in complexity, and they had trouble figuring out how to get rvm to work in their environments. ).
People try to be really sensitive not to insult rvm. And I've tried to be sensitive here, while still saying what I perceive. Lots of people like rvm, for sure. And rvm was first, and a huge boon compared to the no options that preceeded it. And nobody wants to be rude, or get into a fight. But people's sensitivity and desire to avoid controversy also means when you google around... you pretty much just find rvm, even though some (many? I don't know) have in fact moved from rvm to chruby and rbenv -- including sometimes moving as their environments become more complicated.
I am not sure it's accurate to say that developers routinely find chruby or rbenv "quickly become inadequate" as environments and dependencies grow in complexity ('quickly'? really?).
It may be that some people with complex scenarios prefer rvm. It would be interesting to hear from them. (for real! I'd be interested!)
I like the sandboxed gemsets that RVM provides. It seems you can do something similar with rbenv if you use this add-on [1].
I've also used the RVM gem programmatically to install gems on the fly in an isolated environment, and optionally tear the whole thing down when the program completes.
> I like the sandboxed gemsets that RVM provides. It seems you can do something similar with rbenv if you use this add-on [1].
There are many ways to skin that cat. It's not a particularly difficult problem to solve. I wrote one of my own[0] - it's worth doing that yourself to understand how it works, I'd say.
> I've also used the RVM gem programmatically to install gems on the fly in an isolated environment, and optionally tear the whole thing down when the program completes.
That's quite an interesting approach - is this for continuous integration?
Concur. I have steadily migrated from rvm to rbenv to chruby because the relative invasiveness of each solution has simplified my development life.
I have not yet been in a position to choose something for deployment, but I would lean heavily toward chruby (-ish; there's no need for it if you pay attention to how little it does, but it helps in development) and chgems (-ish; same reason) with bundler.
RVM should definitely not be used in production. I would generally argue against using rbenv in production at this point, too, as all you need to know is the right environment variables to have set for your application to make sure everything else is clean.
Docker is a bit orthogonal, IMO. One key problem these tools solve is getting a specified version of ruby onto a host at a granularity other that "whatever's in my distro's package repo". It's certainly possible to simplify matters and just use ruby-build[1] to normalize ruby acquisition. AFAICT, this is out of scope for Dockerfiles in recent incarnations.
> (from the link): To paraphrase Jonathan Jackson, RVM is to Rails as rbenv is to Sinatra.
I think that's overstating the difference quite a bit. If rbenv is Sinatra, RVM is a lot closer to Padrino than Rails.
> As for me and mine, I'm in the land of docker now...
This is exactly where I'm headed on the deployment side of things, but on the developer workstation side, where Rubyists are overwhelmingly Mac users, Docker isn't an option, if the developer wants to work natively rather than inside a VM.
Add me to the list of people that would like more information about the rvm vs rbenv question. I switched to rbenv a few months ago because I wanted something to manage my ruby version only, not gemsets and the rest and I use bundler and shims now.
Yes more opinions :) I'm a relatively new Ruby developer so tend to swing whichever way the last good article I read leads me towards, so more is always better
I hate (yes, it's that strong a word) the problems related to versioning in Ruby ... and even with RVM, you have to figure out which gems are compatible. My solution is to get rid of my Ruby applications. I'm not a Ruby developer, and my career path isn't likely to afford me the time to really learn it.
I'm a Java developer, and we have our own version of dependency hell (that I've learned to avoid and/or navigate), so I'm not trolling, but rather wanted to point out that often issues like dependency management (there are others) simply cause marginal developers to leave.
> often issues like dependency management (there are others) simply cause marginal developers to leave.
I think that's true, and true in just about every language/environment, it's not unique to ruby, right? Dependency management often causes marginal developers to leave, in many langauges/environments.
Dependency management itself has gotten a lot better in ruby -- bundler is pretty great.
But multiple ruby version management is still a mess. I wish ruby would have a single dictatorial-blessed solution to multiple ruby version management, like I understand python to be.
And even bundler isn't perfect, for sure -- I wish bundler was more integrated with rubygems, which would for instance make the `bundle exec` dance unneccesary.
Interestingly, both of these issues, as I see it, are related to the decentralized open source nature of the ruby ecosystem. Which has plusses and minuses.
(And both dependency management and multiple version management can be hell in Java, for sure. I am not a Java developer, and the most common barrier I run into when trying to deal with Java is... maven. And last time I had to run multiple versions of the JVM on one machine, it was hell. I hope it's gotten better.)
> I think that's true, and true in just about every language/environment
Agreed, although it seems as if nodejs may have solved most of the hard problems in this area by way of their unique require() module loader and the design of npm. After learning it, I wish every package manager worked that way.
Ran into same issues with nodejs. If one of your dependencies use libxy 1.2 and your app depends on libxy 1.4, you have to be careful which one gets loaded first and hope one is compatiblew with the ohter. Good luck if the APIs are different. NPM seems to solve the problem but it really doesn't.
This shouldn't be an issue at all. Your app would get libxy 1.4, and your dependency would get libxy 1.2. It shouldn't matter which is loaded first, and unless those modules somehow store something globally, they shouldn't conflict in any way.
npm does solve the "multiple versions of a library are used by different packages", unless that libxy you were using did something fishy. Can you give more details?
I agree about npm. Having the individual node_modules fixes a lot of dependency management issues. That said, I'm not a fan of Nodd but if I could steal two things from them it would npm and Isaac.
> I think that's true, and true in just about every language/environment, it's not unique to ruby, right?
There's a bigger dependency management problem where you need to distribute source code to users of tools rather than distributing compiled code.
> I wish ruby would have a single dictatorial-blessed solution to multiple ruby version management, like I understand python to be.
As I understand, the competing Ruby solutions (unlike the Python solution) attempt to manage versions that are not even from the same project, which naturally makes a single dictatorial-blessed solution problematic, as there is no dictator (or even central project) for the entire Ruby ecosystem, even if there is for the mainline interpreter.
This is the exact reason I'm migrating new things straight to go. Once I've gotten the updated blob (binary or script/whatever really) to where it needs to be. I'm done, at compile time I can deal with dependencies, don't need to have a metric ton of stat calls flying around from require and other nonsense.
I'm getting to the point that the troubles encountered with Python/Perl/Ruby and dependency management has basically made me go, ok fine, i'll go back to c this is getting ridiculous.
Yet go is a dependency nightmare! Dealing with more than one developer on a project with dependencies is incredibly difficult due to the insane decision to not support locking a dependency to a specific version.
I'm actually quite interested in how to fix that. The naive solution that springs to mind is sticking a local cache between my dev environment and the upstream sources, where I can control precisely what versions are available. Is that doable?
Our quick "solution", was just tar cvf up the dependencies and use that.
Alternatively godep as noted below, or you could get creative with git submodules or clone the repos to a local cache.
The reason go is simpler is you only need to deal with this at compile time, and thats what the ci server is for. My goal is removing runtime checks for crap and dealing with package versions every time I update things.
Go is more akin to c really here, and in my not so humble opinion it is a simpler task to sort out dependencies at compile time than on every system I need to deploy to.
> There's a bigger dependency management problem where you need to distribute source code to users of tools rather than distributing compiled code.
At first I nodded my head to myself, but after thinking about it, I'm not actually sure that's true.
You can still have dependencies with binary distribution (if using dynamic linking etc). apt, yum, etc, were invented to deal with this right?
And it can still be a nightmare if you have two different things on your system that need different versions of the same dependency -- even a binary dependency. Have you tried to deal with two different binaries that need different versions of libxml? It can be nightmarish.
The dependency management issues that come with distributing interpreted source like Ruby are superset of the issues that come with binary distribution.
That's not to say that binary distributions can't also have dependency nightmares.
I'm still suspicious. What's an example of a category of dependency problem that only effects interpreted source and not binary? I can't think of any.
Whether the files on disk are machine code (binary) that will be executed directly by the machine, or some other kind of code that will be executed by an interpreter -- I can't think of any dependency issues effected by that.
Ah, wait I can think of exactly one, issues with depending on a certain version of the interpreter. That's it.
Yes ... I specifically said I had similar issues with Java because I didn't want to appear to be targeting Ruby. I also know python, and I've gotten stuck with PIP a couple times. I'd consider myself an expert with Maven, and I don't tend to have issues with that (anymore). And I think the model used for Maven (and Ivy) is perfect (a central repository of artifacts by GAV).
But I've seen people give up due to the learning curve of learning Maven, and I agree that this is a hard problem in general. I think (as noted below) that it's an even harder problem for scripting languages that deliver packages via source ... and I don't have a solution to offer.
Perhaps the best thing we can do is help each other out with the tools we're comfortable with? An apprenticeship program?
Just saying but dependency management in PHP is pretty great. The only thing I need to really worry about is where the library requires a PHP version higher then mine.
I have yet to have trouble with composer packages to the extent I have trouble with basic ruby gems. The funny part is when you get gems that require multiple versions of the same gem. That just makes me laugh :)
It's awfully brave of you to come out and say that around these parts. Suggesting that PHP gets anything right tends to bring out lots of people ready to tell you why you're WRONG wrong wrong wrong WRONG.
I think you're right, mind you. Actually, for all of its other quirks and misfeatures, PHP has probably given me the least difficulty with dependency management over the last decade. (Granted, that's in part because before Composer took off all we really had was PEAR, and it never seemed to grab much mindshare.)
The "bundle exec dance" is unnecessary. Bundler doesn't need to be more integrated, it needs to be less integrated. Half the mess people get into is because the boundaries between these systems break down.
I've literally never found myself in a situation where the dependency tree of a ruby cli utility has been incompatible with what's in the current $GEM_HOME. As and when it happens, I'll see about giving it a separate $GEM_HOME to play with. That's the only situation I can think that binstubs in addition to what `gem install` provides make sense, too.
I was a full time Python developer for years and can attest that virtualenv + ... easy_install? pip? wat?! scared off a lot of marginal developers.
It's a good cautionary tale for any language/platform that wants to claim Ease of Use and Low Barrier to Entry (as it seems both Python and Ruby do).
Hopefully Python 3.4 bundling virtualenv and pip will ease the pain, but it's still a shame these otherwise easy to use scripting languages ended up with such complex sandboxing mechanisms for even trivial use cases (e.g.: my simple script has 1 third party dependency).
Dependency hell isn't a language issue, and the concept of RubyGems or any other language-specific dependency management system is fundamentally broken because it's impossible to manage all your dependencies with it. You resort to nested dependency management--i.e. RVM to manage your Ruby installations, then Bundler to manage the gems inside those installations, with some patchwork for the MySQL client your mysql2 gem has a dependency on (but can't declare or guarantee in RubyGems) and it works...kind of. For now.
If you bundle install with the `--path` flag (which you should), you can specify the location the gems will be installed (typically something like `--path vendor`) which gives you the ability to easily remove the gems the project uses all at once.
Coupled with `bundle package` which stores all the .gem files in vendor/cache, you can ensure that your application always has its gem dependencies available.
The RVM 2.0 plan doc[1] doesn't seem touch on one of my serious problems with RVM: how will it implement ruby environment integration with the shell? Specifically, I've found that RVM's use of shell functions is horribly brittle in some important cases. So much so that I've banished it from all environments that I control (to date, in favor of rbenv and/or ruby-build).
For comparison, rbenv simply needs ~/.rbenv/bin and ~/.rbenv/shims added to $PATH. I'm all for magic when it's seamless[2], but I've not found that to be the case with RVM.
Using PATH makes it quite clear in any given execution context whether rbenv is managing a command.
As I said elsethread, I haven't yet considered production, but I just switched to chruby for my development environment rather than rbenv. I still use ruby-build when I need (I just needed a version not supported by ruby-install), but I have switched wholesale to chruby, and having found chgems in researching a different answer, I may look at using that as well.
chruby really is the simplest possible thing you can do to solve this problem, and in combinations with chgems, it solves isolation better than RVM does without the brittleness of the shims that rbenv has (ultimately why I moved away from rbenv). Installs are substantially easier with ruby-install and/or ruby-build, although RVM is probably better at this part in general. Extract that out from RVM and I'd consider using it.
I'd agree. Something as simple as chruby makes having multiple interpreter/gemset versions easily usable from something like cron without introducing a lot more overhead, though, or having to remember to put all the variables &c. in place everywhere you need them.
So Engine Yard ends their support of JRuby in 2012. Then, just a few weeks ago, they end support for Rubinius. Now, they'll be ending support for RVM next week... A shift in strategy? Financial troubles? Either way, it seems they need to update their "Engine Yard Loves Open Source" page: https://www.engineyard.com/community/open-source
> We are proud to employ and support contributors to such projects as Lithium, Travis CI, Rubinius and RailsInstaller. Check out the comprehensive list of open source projects we’re involved in below.
That fact hasn't changed (at least, not until they start firing people)
Oh how fickle you are. A company that supports an open source project out of pocket for two years now doesn't love open source because they have moved onto other things? Over time, technologies change, stabilize, and/or become obsolete, expecting them to support one project forever is silly and boring.
How about: dear Engine Yard, thanks for 730 days of open source love, can't wait to see where you invest your time next.
I don't disagree, which is why I'm wondering if this is a case of not having enough money to continue supporting these projects, or a case of seeing the momentum or the need for support in open source changing to something new. So far, though, I've only seen Engine Yard drop support for projects. If, tomorrow, they announced that they were starting to support a handful of Go or node.js projects, then I think we'd all have a much different view on this news.
We have a long history of supporting and investing in Open Source projects, especially those that can benefit our customers and the different OSS communities we participate in.
Like all companies, we have budgets for all sorts of activities, and sponsoring open source software is no exception. Also, like every other company, we review on an annual basis, where we allocate our budgets.
The decision to stop financially supporting any project is down to our assessment of what we've been able to help that project to achieve, and if there are opportunities to invest in other projects that are at a different stage in development, or if it relates to a specific customer need.
As has been pointed out elsewhere in this thread, the Engine Yard platform now supports Ruby, PHP and Node JS, and will soon be supporting Java, as well as a number of different databases.
Engine Yard has always contributed to the communities that its customers come from, and adding platform support for these languages and databases means that we need to consider open source projects in those communities as beneficiaries of our financial support.
Go was born in Google. Docker was born in dotCloud. Each of these projects are really "moving the chains" in my world. Perhaps EngineYard is looking at this and thinking of ways they could focus on something which could be equally as important.
Also, I just went to the EngineYard web site and Ruby isn't mentioned any more prominently than the other ecosystems it supports. Why keep supporting projects in the Ruby ecosystem when you have moved into a much wider world?
First time I've ever felt compelled to actually leave a comment on HN. And full disclosure - I work at Engine Yard.
Thanks Brian Shirai, Michael Papis, Wayne Sequin, Kirk, Evan, Dr. Nic, etc... and Engine Yard for the support of all these projects. Getting to working with these gents has been one of the highlights of the last few years for me.
Here we go again. We've got companies building skytowers using the steel and concrete we fund with bake sales. Our most important open source projects are dependent on corporate philanthropy that can disappear overnight.
We can debate the merits of RVM/chruby/rbenv yet all agree that open source version management projects are essential infrastructure for Ruby. Sure, we're grateful that EY funded RVM (and other projects) for so long. But what now?
I contributed $50 to the RVM Bountysource campaign.But a one-shot charitable fundraiser is a slim reed on which to sustain a project like this. Tens of thousands of developers use RVM. And the companies they work for spend millions to develop businesses that could not be be built without the infrastructure provided by open source projects such as RVM. It's skytowers funded by bake sales.
The amount of money raised so far for rvm's current crowdfunding is about the amount that the top receiver on Gittip might get in 20 weeks. https://www.gittip.com/
You say Gittip is trying. That's true, but I think they slipped into a slow growth pattern months ago. At its current rate it would take years for it to be a viable way of funding more than a handful of open source hackers.
> The amount of money raised so far for rvm's current crowdfunding is about the amount that the top receiver on Gittip might get in 20 weeks. https://www.gittip.com/
That is not a technical problem, that is a social one. The OP said
> But a one-shot charitable fundraiser is a slim reed on which to sustain a project like this.
And he is correct, the gittip style is probably better for long-term but faces problems as you pointed out, although again, I do not think any of them are technical in nature.
(Probably the biggest problem being the complete lack of companies on gittip et al and the feeble amounts, in terms of companies' budgets anyway.)
This supports my point. My point is that Gittip is irrelevant and there's no reason to believe it will become relevant. If it were a technical problem and yet had reached its current level of success, I would think that if they fixed their technical problems, it might become relevant. Since it's a non-technical problem (social problem, positioning problem), how to fix it is unknown. The quickest path would very likely involve tearing the whole thing down and starting over again.
I think RVM's played out. We can see the problems that approach comes with, so now we can move on to better things that don't have such high maintenance costs. That's the question we should be asking - why should a tool like this need funding to this extent?
I wish people wouldn't freak out so much about this. RVM is pretty mature at this point, and there are some really great alternatives like rbenv and chruby.
Some time ago I blogged about how we stopped using RVM in production: http://blog.arkency.com/2012/11/one-app-one-user-one-ruby/ . Many people here said that RVM might be over-complicated for the simplest cases and I think in production when there is only one app is the most simple usecase that you can get and RVM is overkill in such situation. In development however RVM is awesome, especially when you are a contractor or freelancer or you work on multiple open source ruby projects and gems and must switch between ruby versions often.
Michał Papis, the current maintainer is a great person and I wish him best luck in funding the project. If you want to meet him in person, he will probably be at wroc_love.rb 2014 conference ( https://twitter.com/wrocloverb ) . Check out what he learned so far on working with RVM1 and what are the plans for RVM2: http://www.youtube.com/watch?v=wN-iIC3S1ZM . I remember that some of the ideas for RVM2 were invented after our Ruby User Group meeting at 3 a.m. in the night, when we were trying to think about most science fiction approaches to RVM such as even a client server architecture. That was a crazy night :)
The biggest problem with RVM1 is that it is written in shell and even if there are people from Ruby community that would like to support this project, their skills are in Ruby language, not bash or zsh, etc. There are plenty of people who would like to help maintaining RVM but they just hit the wall when they see the amount of bash code in the project.
71 comments
[ 3.4 ms ] story [ 165 ms ] threadAs for me and mine, I'm in the land of docker now...
Additionally, some of the schedule on that BountySource campaign makes me especially wary. If most of the code is rewritten in Ruby, presumably it would need to build/install Ruby during its own installation so it can be used afterwards. If the GUI relies on JRuby, it would need to build that during installation as well. Suddenly RVM becomes less easy to install.
It's a known problem and one of the current big design issues, especially because rvm is so complex today in what it's capable of on the user's behalf, so we plan to get that right first time as much as we can.
I agree with you on both of your points: the BountySource page is a bit hand wavy, although there's only so much room to spell out what we think our benefits are; that rvm can make life more complicated, not simpler.
I come to the project late in its life and I'm well aware it's a bit of a beast in many ways, so I can at least say that I'll be pushing Michal towards simplicity. It's one of the reasons 2.0 exists, rather than us heading towards 1.3 instead. It's just too hard to make large changes to 1.2 now, mostly because of the complexity inherent to being a shell program that works (mostly!) portably on the myriad OSes we now support.
> Tools like rbenv or chruby can work well in simple scenarios, especially if you’re very skilled with the Unix shell. However, as environments and dependencies grow in complexity, these tools quickly become inadequate. RVM seems more “complicated” because it does a lot more to make handling these scenarios easy.
> To paraphrase Jonathan Jackson, RVM is to Rails as rbenv is to Sinatra. Sinatra is a lightweight framework whereas Rails is much more robust. Sometimes Sinatra just fits, and other times you'd be a fool to not go with Rails.
I think people with complicated scenarios have had... mixed experiences with whether rvm really makes complex scenarios easy. I suspect many people with complex scenarios prefer a simple tool like rbenv or chruby (disclosure: I prefer chruby having worked with all three), which they can then figure out themselves how to invoke to do exactly what they need.
It may be that some people with complex scenarios prefer rvm. It would be interesting to hear from them. (for real! I'd be interested!)
But I suspect that the bulk of rvm users are not actually sophisticated users with complicated scenarios, but instead beginner users with fairly simple scenarios. For a variety of reasons. Becuase rvm is what you find when you google. Because rvm holds out the promise of not making you understand anything about what it's doing or anything about bash or shell environment, and having it Just Work (whether it fulfills that promise... especially in non-simple scenarios... there are mixed opinions. There are definitely some people who have moved from rvm to rbenv or chruby in fact as their environments have grown in complexity, and they had trouble figuring out how to get rvm to work in their environments. ).
People try to be really sensitive not to insult rvm. And I've tried to be sensitive here, while still saying what I perceive. Lots of people like rvm, for sure. And rvm was first, and a huge boon compared to the no options that preceeded it. And nobody wants to be rude, or get into a fight. But people's sensitivity and desire to avoid controversy also means when you google around... you pretty much just find rvm, even though some (many? I don't know) have in fact moved from rvm to chruby and rbenv -- including sometimes moving as their environments become more complicated.
I am not sure it's accurate to say that developers routinely find chruby or rbenv "quickly become inadequate" as environments and dependencies grow in complexity ('quickly'? really?).
I like the sandboxed gemsets that RVM provides. It seems you can do something similar with rbenv if you use this add-on [1].
I've also used the RVM gem programmatically to install gems on the fly in an isolated environment, and optionally tear the whole thing down when the program completes.
1. https://github.com/jf/rbenv-gemset
There are many ways to skin that cat. It's not a particularly difficult problem to solve. I wrote one of my own[0] - it's worth doing that yourself to understand how it works, I'd say.
> I've also used the RVM gem programmatically to install gems on the fly in an isolated environment, and optionally tear the whole thing down when the program completes.
That's quite an interesting approach - is this for continuous integration?
[0] https://github.com/regularfry/gemenv.git, https://github.com/regularfry/rv.git
I have not yet been in a position to choose something for deployment, but I would lean heavily toward chruby (-ish; there's no need for it if you pay attention to how little it does, but it helps in development) and chgems (-ish; same reason) with bundler.
RVM should definitely not be used in production. I would generally argue against using rbenv in production at this point, too, as all you need to know is the right environment variables to have set for your application to make sure everything else is clean.
[1] https://github.com/sstephenson/ruby-build
I think that's overstating the difference quite a bit. If rbenv is Sinatra, RVM is a lot closer to Padrino than Rails.
> As for me and mine, I'm in the land of docker now...
This is exactly where I'm headed on the deployment side of things, but on the developer workstation side, where Rubyists are overwhelmingly Mac users, Docker isn't an option, if the developer wants to work natively rather than inside a VM.
I'm a Java developer, and we have our own version of dependency hell (that I've learned to avoid and/or navigate), so I'm not trolling, but rather wanted to point out that often issues like dependency management (there are others) simply cause marginal developers to leave.
I think that's true, and true in just about every language/environment, it's not unique to ruby, right? Dependency management often causes marginal developers to leave, in many langauges/environments.
Dependency management itself has gotten a lot better in ruby -- bundler is pretty great.
But multiple ruby version management is still a mess. I wish ruby would have a single dictatorial-blessed solution to multiple ruby version management, like I understand python to be.
And even bundler isn't perfect, for sure -- I wish bundler was more integrated with rubygems, which would for instance make the `bundle exec` dance unneccesary.
Interestingly, both of these issues, as I see it, are related to the decentralized open source nature of the ruby ecosystem. Which has plusses and minuses.
(And both dependency management and multiple version management can be hell in Java, for sure. I am not a Java developer, and the most common barrier I run into when trying to deal with Java is... maven. And last time I had to run multiple versions of the JVM on one machine, it was hell. I hope it's gotten better.)
Agreed, although it seems as if nodejs may have solved most of the hard problems in this area by way of their unique require() module loader and the design of npm. After learning it, I wish every package manager worked that way.
npm does solve the "multiple versions of a library are used by different packages", unless that libxy you were using did something fishy. Can you give more details?
There's a bigger dependency management problem where you need to distribute source code to users of tools rather than distributing compiled code.
> I wish ruby would have a single dictatorial-blessed solution to multiple ruby version management, like I understand python to be.
As I understand, the competing Ruby solutions (unlike the Python solution) attempt to manage versions that are not even from the same project, which naturally makes a single dictatorial-blessed solution problematic, as there is no dictator (or even central project) for the entire Ruby ecosystem, even if there is for the mainline interpreter.
I'm getting to the point that the troubles encountered with Python/Perl/Ruby and dependency management has basically made me go, ok fine, i'll go back to c this is getting ridiculous.
That plus clang has made me happy.
Alternatively godep as noted below, or you could get creative with git submodules or clone the repos to a local cache.
The reason go is simpler is you only need to deal with this at compile time, and thats what the ci server is for. My goal is removing runtime checks for crap and dealing with package versions every time I update things.
Go is more akin to c really here, and in my not so humble opinion it is a simpler task to sort out dependencies at compile time than on every system I need to deploy to.
At first I nodded my head to myself, but after thinking about it, I'm not actually sure that's true.
You can still have dependencies with binary distribution (if using dynamic linking etc). apt, yum, etc, were invented to deal with this right?
And it can still be a nightmare if you have two different things on your system that need different versions of the same dependency -- even a binary dependency. Have you tried to deal with two different binaries that need different versions of libxml? It can be nightmarish.
That's not to say that binary distributions can't also have dependency nightmares.
Whether the files on disk are machine code (binary) that will be executed directly by the machine, or some other kind of code that will be executed by an interpreter -- I can't think of any dependency issues effected by that.
Ah, wait I can think of exactly one, issues with depending on a certain version of the interpreter. That's it.
But I've seen people give up due to the learning curve of learning Maven, and I agree that this is a hard problem in general. I think (as noted below) that it's an even harder problem for scripting languages that deliver packages via source ... and I don't have a solution to offer.
Perhaps the best thing we can do is help each other out with the tools we're comfortable with? An apprenticeship program?
I have yet to have trouble with composer packages to the extent I have trouble with basic ruby gems. The funny part is when you get gems that require multiple versions of the same gem. That just makes me laugh :)
I think you're right, mind you. Actually, for all of its other quirks and misfeatures, PHP has probably given me the least difficulty with dependency management over the last decade. (Granted, that's in part because before Composer took off all we really had was PEAR, and it never seemed to grab much mindshare.)
https://github.com/mpapis/rubygems-bundler
It's a good cautionary tale for any language/platform that wants to claim Ease of Use and Low Barrier to Entry (as it seems both Python and Ruby do).
Hopefully Python 3.4 bundling virtualenv and pip will ease the pain, but it's still a shame these otherwise easy to use scripting languages ended up with such complex sandboxing mechanisms for even trivial use cases (e.g.: my simple script has 1 third party dependency).
But after you are done with the project, there is no easy way to delete the gems that the project uses all at once.
> But after you are done with the project, there is no easy way to delete the gems that the project uses all at once.
This is part of why I wrote gemenv (https://github.com/regularfry/gemenv.git). It gives you a $GEM_HOME in the project directory, in the style of virtualenv.
Coupled with `bundle package` which stores all the .gem files in vendor/cache, you can ensure that your application always has its gem dependencies available.
Here's a great article with more information about all the above: http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-a...
For comparison, rbenv simply needs ~/.rbenv/bin and ~/.rbenv/shims added to $PATH. I'm all for magic when it's seamless[2], but I've not found that to be the case with RVM. Using PATH makes it quite clear in any given execution context whether rbenv is managing a command.
[1] https://docs.google.com/document/d/1xW9GeEpLOWPcddDg_hOPvK4o...
[2] By "magic", I mean underlying complexity that creates practical simplicity.
chruby really is the simplest possible thing you can do to solve this problem, and in combinations with chgems, it solves isolation better than RVM does without the brittleness of the shims that rbenv has (ultimately why I moved away from rbenv). Installs are substantially easier with ruby-install and/or ruby-build, although RVM is probably better at this part in general. Extract that out from RVM and I'd consider using it.
> We are proud to employ and support contributors to such projects as Lithium, Travis CI, Rubinius and RailsInstaller. Check out the comprehensive list of open source projects we’re involved in below.
That fact hasn't changed (at least, not until they start firing people)
How about: dear Engine Yard, thanks for 730 days of open source love, can't wait to see where you invest your time next.
When it's basically a charity, then it's probably going to get the axe pretty early on when there are financial troubles.
We have a long history of supporting and investing in Open Source projects, especially those that can benefit our customers and the different OSS communities we participate in.
Like all companies, we have budgets for all sorts of activities, and sponsoring open source software is no exception. Also, like every other company, we review on an annual basis, where we allocate our budgets.
The decision to stop financially supporting any project is down to our assessment of what we've been able to help that project to achieve, and if there are opportunities to invest in other projects that are at a different stage in development, or if it relates to a specific customer need.
As has been pointed out elsewhere in this thread, the Engine Yard platform now supports Ruby, PHP and Node JS, and will soon be supporting Java, as well as a number of different databases.
Engine Yard has always contributed to the communities that its customers come from, and adding platform support for these languages and databases means that we need to consider open source projects in those communities as beneficiaries of our financial support.
Also, I just went to the EngineYard web site and Ruby isn't mentioned any more prominently than the other ecosystems it supports. Why keep supporting projects in the Ruby ecosystem when you have moved into a much wider world?
Thanks Brian Shirai, Michael Papis, Wayne Sequin, Kirk, Evan, Dr. Nic, etc... and Engine Yard for the support of all these projects. Getting to working with these gents has been one of the highlights of the last few years for me.
We can debate the merits of RVM/chruby/rbenv yet all agree that open source version management projects are essential infrastructure for Ruby. Sure, we're grateful that EY funded RVM (and other projects) for so long. But what now?
I contributed $50 to the RVM Bountysource campaign.But a one-shot charitable fundraiser is a slim reed on which to sustain a project like this. Tens of thousands of developers use RVM. And the companies they work for spend millions to develop businesses that could not be be built without the infrastructure provided by open source projects such as RVM. It's skytowers funded by bake sales.
The amount of money raised so far for rvm's current crowdfunding is about the amount that the top receiver on Gittip might get in 20 weeks. https://www.gittip.com/
You say Gittip is trying. That's true, but I think they slipped into a slow growth pattern months ago. At its current rate it would take years for it to be a viable way of funding more than a handful of open source hackers.
That is not a technical problem, that is a social one. The OP said
> But a one-shot charitable fundraiser is a slim reed on which to sustain a project like this.
And he is correct, the gittip style is probably better for long-term but faces problems as you pointed out, although again, I do not think any of them are technical in nature.
(Probably the biggest problem being the complete lack of companies on gittip et al and the feeble amounts, in terms of companies' budgets anyway.)
Michał Papis, the current maintainer is a great person and I wish him best luck in funding the project. If you want to meet him in person, he will probably be at wroc_love.rb 2014 conference ( https://twitter.com/wrocloverb ) . Check out what he learned so far on working with RVM1 and what are the plans for RVM2: http://www.youtube.com/watch?v=wN-iIC3S1ZM . I remember that some of the ideas for RVM2 were invented after our Ruby User Group meeting at 3 a.m. in the night, when we were trying to think about most science fiction approaches to RVM such as even a client server architecture. That was a crazy night :)
The biggest problem with RVM1 is that it is written in shell and even if there are people from Ruby community that would like to support this project, their skills are in Ruby language, not bash or zsh, etc. There are plenty of people who would like to help maintaining RVM but they just hit the wall when they see the amount of bash code in the project.