I’ve been working on getting mailr to work. It’s not easy.
There’s a host of tiny deployment issues that have to be smoothed out. Shebangs are wrong, developed on a Debian-variant, I can tell — the shebang reads #!/usr/bin/ruby18. There’s dependencies on Rails being installed, being the correct version, and being in a similar place as on the developer’s machine.
It ships in development mode, so one has to understand rails’ three-database development framework before you can install it. The docs assume you know this — I only know it having worked with Rails a little, but your usual sysadmin is gonna have a fit when first they have to install ruby, then install rails, then install a couple other dependencies, then start learning how to develop with rails to get an app off the ground.
There’s evidence in the rails environment.rb that the rails files were copied into vendor/ as is typical of rails, but they’ve been sloppily omitted — I’d prefer that rails worked this way from the start, really, since making local copies is equivalent to static linking. Great if disk space and memory are free, I guess. Makes it a pain to roll out a library update to a bunch of apps, though. Sloppily ripped out is bad, too.
It also requires a DRB backend process to handle persistent connections. That’s no problem, though I had to correct some of the code (and it requires it to be run with the current directory being lib/ in the mailr distribution. There’s no startup script for it, no SysVinit script, no suggestion of a cronjob to start it, nothing. You’re on your own here.
This is something I see a tendency toward in rails. The conventions that are convenient for a developer with a shell always open within the rails app files are a hindrance to actual deployment on a unix system. There’s path issues, lack of startup scripts, and you have to understand rails development process to even get an app running. Keep working, guys.
Oh, and it doesn’t work with my imapd.