Engine Yard's sponsorship of RVM is coming to an end
rvm.io
rvm.io
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.)
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.)
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.
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).
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 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)
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.
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.)
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.
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.
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?
As for me and mine, I'm in the land of docker now...
> 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 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.
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.
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
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.
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.
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.
But after you are done with the project, there is no easy way to delete the gems that 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.
Here's a great article with more information about all the above: http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-a...
> 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.