I'm the OP of the mailing list post, and have maintained Capistrano for the last 5 years. I'm passionate about providing great open source tools, my business and reputation are built on Capistrano and I don't want to give it up, but it's destroying me.
Maybe you need to take some time off completely if you're this burned out. Go travel and come back to software and life in a few months to a year. Maybe you'll be inspired to start something new, or maybe there will be something completely different you'll want to do.
You'll always be the creator of Capistrano and for this your reputation will live on. If you've got clients that love you, your business will also thrive. I think your fear of letting go is probably unwarranted, and in any event your happiness should come first.
Have to second this; your love and dedication is too much to lose, both for the community and for yourself. Take a break, ignore the haters, stay happy.
I just want to say that I love Capistrano. Even though I don't use it all the time, I still think it's a really great way of deploying when you aren't in a container-based workflow and you just want a quick way of running remote commands from your local machine.
As for your comment, "Ruby is pathologically difficult to install correctly on modern Linux distributions", I disagree wholeheartedly with this. It may be more difficult to install than a simple `apt-get`, but if you're used to compiling from source and you know what the hard dependencies are, it's really not a huge problem. ruby-install and ruby-build of course make this easier but those tools don't require the use of RVM or rbenv, especially on a machine where you know there will only be one Ruby. However, you're correct in the assumption that Ruby could be a lot easier to install if the language creators would move towards that. That said, I think there are a lot of people who are unfairly blaming you for their own misunderstandings of what these tools do and how they are used. For example, chruby or rbenv is absolutely vital on my dev machine because I work with projects using different versions of Ruby. But it's just bad practice to have a production box running multiple versions of Ruby, in my opinion.
I really feel that the users you've interacted with may have been frustrated by their own misunderstanding of the tools they're using, because it's really not as hard as a lot of people make it out to be...
I compile Ruby from source for all my deployments (Debian based). I only need to apt install a handful of build deps and the build goes off without a hitch every time.
Can someone direct me to the common complaints, or outline the common complaints here?
Your method is sane, the problem is with RVM and rbenv, which everyone uses and depend on hacky implicit shell BS (rbenv less so, but it's still there). Build from source and use the full path to the interpreter is the only sane method IMO.
That's 9 lines of shell if you exclude comments, and includes the MD5 check. I've updated these commands a few times as Ruby has advanced, but most of the changes come with my distro updates. For example, the Debian 7 release required an update to most of the libs that Ruby depends on. Otherwise, it's been relatively trouble free.
1: It's not really a build script. It's a listing of the shell commands you'd need to install Ruby manually. I extracted them from my build scripts.
I think the fundamental problem is that on your laptop you use the system's package manager to manage gems and dependencies, while on the server you suddenly are forced to use RVM.
> ...while on the server you suddenly are forced to use RVM.
Why are you forced to use RVM on the server? A great number of the issues people face when trying to deploy Rails apps are environment based. Tools like rbenv and RVM are environment managers. They make all kinds of changes to things like PATH, GEM_HOME, etc.
In a production server environment, you want consistency and simplicity. Yes, you can use tools like rbenv or RVM, you but add layers of environment management on top of the base server environment. When you use these tools to manage Ruby on your server, any process or daemon that needs Ruby will first have to ensure that these tools are loaded and invoked properly. It's a layer of indirection that I feel a strong incentive to avoid.
Don't get me wrong. I'm not saying they're not good tools. Quite the opposite. I'm a huge fan of RVM, rbenv, and chruby. I have a deep appreciation of their contribution to the Ruby ecosystem, but I'm one guy. I have a reasonable understanding of Linux system administration, but the more layers of complexity I add, the deeper the water gets. At some point, I'm in over my head.
There are two really great options for installing Ruby on your production servers:
Note: Most Linux distributions give /usr/local/bin priority in PATH by default, which is why I use it instead of /opt. Using /usr/local/bin means you don't need to modify PATH.
1) Use ruby-build [1]. This is the plugin that rbenv uses to install Ruby, and you can use it without rbenv. Once it is installed, this simple invocation will get you a working Ruby install:
ruby-build '2.0.0-p247' '/usr/local'
Because of the reasons outlined in the note above, this type of Ruby install will "just work", even for utilities that shell out with bare shells like `sh -c 'some command here'`. This is because we installed to paths that work with the bare minimum environment.
2) Install from source. In the example above, ruby-build really isn't doing all that much. You still have to have the basic deps (build-essential, zlip, ssl, readline) in place in order to build Ruby, and you have to remain aware of any caveats introduced by new OS or Ruby releases.
I use option 2.
A great way to keep up with what's required to install Ruby on your system is to look at what tools like rbenv and RVM are doing under the hood. These tools act as collectors for the little hacks and workarounds (e.g., ref URL 2 below) that are occasionally required to install Ruby. If you're running a mainstream distro on a recent release, you really shouldn't need much in the way of hacks/workarounds these days. OS X is where a lot of the trouble lies.
EDIT: Above I said, "[ruby-build] isn't doing all that much", which isn't entirely fair. Ruby-build does do some really nice things like check MD5 hashes. It also checks for common caveats, which I kind of played off. I do the work of looking out for these things, but I'd certainly understand why someone wouldn't want the hassle, and ruby-build does a fantastic job of keeping up with these hassles and automating them away. In short, I want to be crystal clear that I am super appreciative of the work that the rbenv and RVM authors do. They are a tremendous asset to the community.
I read this from time to time and I don't get it. This is literally what I do on Ubuntu LTS:
sudo apt-get install build-essential openssl-dev zlib1g-dev
wget http://ftp.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p0.tar.gz
tar xvfz ruby-2.0.0-p0
cd ruby-2.0.0-p0
./configure && make && sudo make install
This is not hard, and it's never caused me any kind of trouble.
A few months ago, I ran into psych/yaml problems doing just the above because I didn't have the right yaml libraries installed.
Also, if you did that and also did something like "apt-get install chef" or something that installs the system ruby, you will have two copies of ruby installed and need to make sure your $path is correct.
I just started learning Chef, and all I can say, vis-a-vis Ruby, is "F%!#, what a nightmare". Now, to be fair, the version of Ubuntu I was on was a bit out of date, and I'm not a "Ruby guy" so I knew bugger all about rbenv, RVM and the like going in. But that was downright painful.
I don't know what life is like for Rails devs, but just getting Chef up and running is painful enough that it killed any latent interest I might have had in ever diving into Ruby.
What was painful about it? Chef provides Debian packages. I added their repository, then apt-get install chef, and it was done. I use chef-solo, and every time it just worked. What sorts of problems did you experience?
I was following one of their tutorials and it had you doing things like using rbenv and bundler, and none of that crap worked right. I don't remember the specific error messages, but it was all crap like "Can't load Gem <such and such>" or "can't load required file <blah>", etc, etc.
In that case, part of the problem was documentation (as far as I can tell in retrospect, I never really needed anything other than the Ruby 1.8.7 I already had installed), but just being exposed to rbenv and the mess of that world left a bad taste in my mouth.
Of course, it's not just Ruby. I have no use for the similar tools for any environment, that purport to let you keep multiple versions installed simultaneously. Whether it's for Python, Groovy, Ruby, whatever. I've come to the conclusion that it's just plain A Bad Idea to do that sort of thing.
Maybe that tutorial was old. Use their Debian packages. It bundles a private Ruby that is only used for running Chef. It always works and never breaks.
Interesting... I guess I didn't find any packages that bundle private Ruby, or if it does it does it behind the scenes and I just don't know it. But what I'm fighting with now, is install some Gems that one of the tutorials has you install... when I run "bundle install", one of the Gems flakes out because it requires Ruby > 1.9.1, and doing a "apt-get install rubygems" earlier apparently made Ruby 1.8.7 the default on this box again.
Ran "update-alternatives" and set Ruby back to 1.9.3 and now when I try to install the Gems, I get failures like:
"in `require': cannot load such file -- mkmf (LoadError)"
I think I'm making progress, but man, this is frustrating.
To be fair though, the basic Chef install is done and working, and I can run "knife client list" and see my clients. It's just that I'm trying to get through this EC2 tutorial and it has you installing this specific list of Gems, and that's where the problems are now. sigh
Yes I can see why installing Ruby is frustrating wit those kinds of errors. The thing is, Debian split Ruby into multiple packages, but made a lot of them not installed by default, which causes a lot of headache for users. The mkmf thing is supposed to be a standard part of Ruby, and most developers assume it is always available, but I Debian put it in `ruby-dev` I think, so you get that error if you don't `apt-get install ruby-dev`.
If you're not a Rubyist and just wants to use Chef, Chef's own Debian packages work great. You can ignore RubyGems and update-alternatives and other stuff, Chef's Debian packages provide everything you need.
I think that Chef should go through the tutorials and clean up the old things.
Yes, you do have to know your deps, but the deps don't change very frequently. Common Ruby build tools will tell you what the deps are for your operating system, even if you're not going to use them in production (I don't).
As far as system Rubies go, I try to keep things simple. I use Debian for my systems, so I know that `/usr/local/bin` will always be first in my path, so that's where I install.
This falls far short of "awful" in my opinion. There are many pieces of software that are far more difficult to compile from source.
Let me reply to myself. Try to automate a Ruby installation on Debian without using a PPA (like the awesome service that Brightbox is providing everyone at http://wiki.brightbox.co.uk/docs:ruby-ng ) or installing a compiler on your production server.
I don't have a problem with Ruby, I have a problem with its clusterfuck of programs that reinvent the package management wheel and assume that you're going to send your work over to magicland where all of the Ops wizards will make it into a working product.
The reason it's that way is because most of these people develop on Macs then hand off to someone to deploy on Linux. They don't know anything but web dev, and with PaaS like Heroku, they're never likely to. My warning, though: if the reason you're on a PaaS is because you have no idea of how to deploy, you're going to be paying an ignorance tax. Make Ruby easier to deploy, and PaaS will end up cheaper.
edit: I have no problem with rvm (or virtualenv) as a container to run different versions of a language and dependencies on the same server. To use those tools to run a single system version for a single application would be silly, but since the tools are completely broken for doing that anyway, it's simply impossible to do and to retain dark, lush hair at the same time.
It might be a problem with your OS/distribution if you feel like it is awful to use in production. FreeBSD, for example, provides an excellent ruby version in it's package repository (and can have all of them installed, 1.8, 1.9, 2.0, rubinius, jruby, etc) and it's very easy to manage. This is true, I am sure, for many linux distributions as well, and many other OSes. I don't see how ruby can be blamed here.
Our company also uses Cap extensively and we really appreciate all your hard working building and maintaining it. I totally feel your pain reading responses about bugs, test coverage, etc. I urge you to consider whether you can get a couple of trusted allies or colleagues involved in putting Cap 3 out. I think it could be a huge boon to those of us who like the idea of modularized code and perhaps you can find a buffer or person who is willing to field some or all of the influx of bug reports (directly ask the community if so!)
Tom `seenmyfate` Clements has been helping to support me over the last three months when I've been very burned out, and has really taken my vision for v3 and made it reality where I wouldn't have been able to. He'll always be around taking care of Capistrano as his company grants him some 20% free time to work on it, I trust him implicitly, and he already has deploy and unregulated commit access.
Tom, if you are on HN, you're the only reason this project has been able to come as far as it has. Thank you.
It's been a pleasure, I'm really proud of what we've built so far. I hope that following a long and well deserved break you'll find yourself itching to return. No-one can deny you've gone above and beyond with a very demanding project, maybe with v2 retired and some additional support the overhead will come down to a much more manageable level.
Lee - We're a small dev shop in the greater Boston area and we use Capistrano exclusively for our deployment process. Frankly, I'm blown away that you've taken this as far as you already have, and completely understand your stance on the community at-large. I think I'd have to echo others before me in saying that sometimes you just need to step back and grab a cocktail. Take a few months away for the sake of self preservation. It's only code :)
if you can't find a successor - just keep in mind that people don't tend to step up unless there is a vacuum. if you were to step down, someone would step up, especially in a community as large as the one you're in.
if it's destroying you, leave. go on a long vacation. it's not worth it. there's no shame or guilt in taking a break or passing on your work.
Lee, we use Capistrano at Scribd for our main Rails app, QA servers and countless other Ruby/Java services. In a world of complaints, we haven't had a single complaint about Capistrano. Thank you.
Just wanted to add my thanks for such a great tool. I've been using cap since the rails 1.x days and it's always worked for me like a charm - I'm so grateful you stepped up to the plate to create & maintain it.
Maybe you can find a way to delegate the bits you don't like about maintaining Capistrano so you don't need to directly manage it yourself? This is probably niave and maybe you are doing this already with v3 but it occurs to me if rails is the main cause of the headaches perhaps you can split that part into a cap-rails gem that is separately managed then you could hand over the reigns to someone else?
Anyways, as mentioned, thank you for a great tool - I very much hope you find a solution that helps you feel good about the situation.
I mean for something as operationally critical like Capistrano, why dont you seriously raise money on Kickstarter, outsource some of the testcases, etc. and be more productive overall.
And please feel free to raise money to fix RubyGems as well ;)
Thank you so much for Capistrano. We use it on a daily basis (several times) and built http://capo.io to make it easier to re-use deploy scripts.
I'm going to take a closer look into the source code and try to help out with issues. It's something I've been wanting to do for a while so I hope I can at least help out a little bit here
Thank you for all of your hard work on Capistrano. We use cap extensively at Simply Measured... as well as a "TurboGC" version of Ruby on an LTS version of Linux (hah!). Perhaps in the future something like containers will provide a better way forward, but for now cap is irreplaceable.
Let's say that you decide to continue. I think that you should get advice from elsewhere than here, from someone whose professional expertise is in the emotions.
Before everyone leaps to conclusions, I'd better clarify
- I am not saying there's anything wrong with you
- I am not excusing the crass behavior which is getting you down.
What I'm saying is that there are almost certainly skills you can learn which will stop this getting to you. I don't know exactly what they are, and most people here don't either (although they will passionately sell you the hammer which worked for their particular nail). Ask an expert.
As I wrote in the mailing list post, it'll be made mainstream this week, as I think it's a general improvement in all areas, at least it's faster, easier to debug, looks and works better, and has better out of the box compatibility with Rails (3 and 4).
Just to say, I love Capistrano - its a great product that I use almost every day. I introduced it at one place I worked and it took deployment time from painstaking hours to minutes.
Thanks very much for your efforts and I am sorry you feel the need to step down from maintenance.
Thank you so very much for your efforts. We use Capistrano at Bigcommerce to deploy our apps and components, and it's saved us from an inevitable pile of shell scripts. :-)
I have never commented anywhere about Capistrano. But, it has been part of a toolchain that has brought me success and improved my life. Thank you very much for all you have done.
