Let's make Rails on OS X easy again!
Getting started with Rails on OS X has gotten hard. When I started working with Rails in 2005, a beginner could get up and running by downloading and running Locomotive. Locomotive made good on the implicit promise of the original Get Excited screencast: within minutes, you too can feel the power of Ruby on Rails.
By the time I became a member of the Rails core team and began work on Rails 3, Locomotive was abandonware. Since OS X shipped with Ruby 1.8, it seemed like a simple `gem install` would do the trick. And for many people, it did.
Since then, the Ruby ecosystem has become increasingly sophisticated, making tools like bundler and rvm (or rbenv, if that's your thing) a part of the standard workflow. And as those tools increasingly became part of the toolchain for experienced developers, we lost track of the complexity of setting up the standard Ruby toolchain.
Even more frustrating, every piece of the toolchain has multiple options, meaning that new developers are faced with needing to choose between rvm and rbenv, Ruby 1.8 and Ruby 1.9, etc.
For experienced developers, these hurdles may not seem particularly large, but they frequently chase away enthusiastic newcomers at exactly the wrong time.
Enough is enough. We need a way to get up and running with Rails that is as conventional and pleasant as Rails itself.
I have a track record of delivering OSS projects. For the past five years, I have worked on a number of popular open source projects. I am probably most well-known for my work on Rails following its merge with Merb, where I was the maintainer.
My goals for Rails 3 were to bring Merb's ethic of modularity and extensibility to Rails, and Rails 3 shipped with a stable plugin API that has paved the way for a richer extension ecosystem. Jose Valim's book, Crafting Rails Applications, illustrates the power of many of these extensions.
When I began work on Rails 3, the Rails ecosystem desperately needed a stable foundation for long-term extensions. Today, the Rails ecosystem desperately needs to get back to basics and make the experience of starting fresh exciting again.
I have the track record and skills to deliver a polished, maintainable solution that can become part of the Rails project. Please help me get this done.
Many of the necessary components for rails.app already exist in some form. I do not want to duplicate existing efforts, where those efforts already solve some part of the larger problem. I will deliver a project that lives in the `rails` organization on GitHub, can be maintained by the Rails team and shipped as part of the official releases.
My plan is to deliver a `.app` that can be downloaded and dragged to the user's `/Applications` folder. At first, the application will have two facilities:
- Install Rails into the system: This will install a working copy of Ruby, Rubygems, Rails and all necessary gems into the user's system, available from the Terminal. It may also install rvm and other common system tools, depending on the feedback I get from the community as I develop this project.
- Open a Terminal with a working Rails environment: This will leave all necessary resources in the `.app` file or `Application Support`, but open a terminal window with the `$PATH` and other variables set up.
The second option will be the preferred option for new users, as it will be a more controlled environment with fewer opportunities for something to go wrong. This will not be a toy Ruby. It will be a full-fledged Ruby environment running in an isolated sandbox. My goal is for this mode to be something I personally would use.
Over time, I imagine that the community would add additional features, such as the ability to start and stop the server, generate files, run migrations, etc. but these are not part of the initial release goals.
The finished project will also include several facilities to help with long-term maintenance:
- It will prompt the user to accept patch-level updates to Ruby or Rails without requiring a new download of the entire package.
- Each `.app` will be a self-contained environment for a given version of Ruby and Rails, so multiple copies can live side-by-side for users who want to work with, for example, Rails 3.1 and Rails 3.2 for different projects.
- The release of a new version of the `.app` will be fully scripted, working off of release tags of the Rails repository. At the very *most* a single rake task will build and deploy new versions and make those versions available to the `.app`'s updater.
- It will be easy to build a nightly build server for people who want to live on the edge.
If time permits, I also would like the framework for building this self-contained `.app` to be useful for other projects (such as Compass/Sass) that have a desire to ship self-contained environments for working with Ruby-based tools.
I am planning on taking some time off of work to work on this project. I will dedicate sustained effort until I can ship an initial release, and then dedicate a number of hours a week on the project during its initial bootstrapping phase.
My goal is to use this time to transition the project over to maintenance by the community in the github rails organization.
Rails.app is an external project to create a standalone distribution of Ruby that comes with the libraries and tools that new Rails projects will need. The code itself should be reusable for other Ruby projects (like Compass), and the UI will be focused around the Rails use case.
Because Rails 4 deprecates support for Ruby 1.8, this means that new Rails 4 users will no longer be able to use their system Ruby to get started with Rails. In general, when I talk about this project making the Rails 4 experience amazing for new developers, I am talking about the fact that one of the best paths for new developers to get up and running is about to be foreclosed, and Rails.app should provide a supportable path to success going forward.
First off, my current plan is to use the money to take some time off from work and ship Rails.app. I plan to leave enough money left over to allocate some dedicated time (as opposed to the ad-hoc time I usually use for my projects) to spend on initial release and maintenance work for a while after the release.
There are some parts of this project that I considered out of scope for the initial release that I will probably be able to do with additional funds:
* Website design: At the very least, I will have a website along the lines of the Bundler website for this project. With additional time and money, I can dedicate more time to the website part of the project during the initial work.
* Making the core a project that can be used by other Ruby-based projects, like Compass/Sass to distribute standalone environments for their users
* The current plan involves both an isolated mode and a mechanism for installing the environment into the system. If I have extra time, I'd like to put more time into making the transition from isolated environment to the installed environment as smooth as possible.
* I've gotten a few very interesting suggestions over the past few days that I will be looking into. One example: integrating ruby-toolbox into the application.
* Feedback that I get throughout the project will also drive what I do with any extra time.
Support this project
- (45 days)