7

Here's my imagined development and deployment process:

  1. Create project directory my_project.
  2. Install the required Ruby version into it.
  3. Install the required gems.
  4. Write some code.
  5. Use fpm to package the whole thing.
  6. Ship the debian package to a production box and install.

I use RVM and Bundler to address some of the pain points but RVM doesn't care about creating relocatable Ruby installations so you can't move ~/.rvm/rubies into the project directory and expect everything to just work out. You have to rewrite all sorts of hard-coded #! lines and in some instances you have to move .so files into the lib directory. I hacked together a set of scripts by scouring the internets that, together, accomplish what I want but the whole thing feels like a huge hack.

I accidentally stumbled on https://github.com/ot/bpt which could be used to build something that would allow for completely relocatable Ruby installations but that project hasn't been touched in more than two years so I'm a little hesitant to build something on top of it.

Is there a more elegant solution to this problem that I'm not seeing? How do people isolate and deploy Ruby projects? I feel like this should be a solved problem.

the Tin Man
  • 158,662
  • 42
  • 215
  • 303
David K.
  • 6,153
  • 10
  • 47
  • 78
  • Most developers I know use RVM / rbenv on server. They install it (and required ruby version) before deploying the application. – Sergio Tulentsev Feb 06 '13 at 05:32
  • @SergioTulentsev: I want to avoid having to install a systemwide or even per user ruby versions. I want a completely self-contained project directory that just works. No users or anything else to worry about. Of course rewriting environment variables is unavoidable in such an instance but I can't find a standardized procedure anywhere for doing this. – David K. Feb 06 '13 at 05:34
  • Once upon a time, there was no RVM. And people were bound to use a single system ruby. But then came Wayne and said "Enough of this". Self-contained app folder sounds like a great idea. So, maybe it's your time to make history :) – Sergio Tulentsev Feb 06 '13 at 05:39
  • 1
    It sounds like a use-case for [chroot](http://en.wikipedia.org/wiki/Chroot). – the Tin Man Feb 06 '13 at 06:32
  • @theTinMan: chroot could work but I'm almost certain there is a way to do it without chroot. `rbenv`, `rvm`, and `ruby-build` are basically almost there. I'm just surprised somebody hasn't taken it all the way and created a tool for making completely relocatable ruby project directories. @SergioTulentsev might be right. I'll probably have to start hacking away at this during weekends and build it myself. – David K. Feb 06 '13 at 06:51
  • What you want seems mostly possible already. Except for the parts where libraries are compiled against system resources (nokogiri, rmagick, sqlite etceteras). Your deb packages would either need to be source and re-compiled on server, or have binaries for most architectures. Also, your workflow seems geared towards Debian-ish on both server and development. It appears (to me) a majority of Ruby devs work on OSX, so I guess that is the main reason why this workflow does not yet exist. – berkes Feb 10 '13 at 09:39

1 Answers1

1

The closest thing to what you're describing is Tokaido, and AFAIK it's still a work in progress. The other project that comes to mind is Vagrant, although it's mostly for development.

sockmonk
  • 4,195
  • 24
  • 40
  • This is all good but it seems a little too specific to OSX and rails. – David K. Feb 12 '13 at 04:36
  • Actually, I did some more reading and this could work. Now I just gotta learn enough about sm framework to reuse the components that statically build ruby. – David K. Feb 12 '13 at 04:53