Of course I know howto install RVM and maintain multiple versions that way, and since I'm a developer I have all the requirements on my own macs (things like xcode etc). Everything is working fine on my own machines.
But how should I distribute my nifty scripts to other mac-users that only have the default 1.8.7 version installed?
I want them to upgrade to 1.9 but I can't expect them to run shell-scripts, rvm (with all its external requirements) etc to be able to run my short 30-line scripts?
Is there a shortcut/tool available so I can get them to upgrade to Ruby 1.9?
Instead of forcing your users to upgrade Ruby, you could package your script into a standalone executable - see SO question on packaging Ruby scripts into Mac OS X applications
There are a few options for automatically setting up development environments.
Thoughtbot's laptop: Laptop is a shell script that turns your Mac OS X laptop into an awesome development machine.
Github's boxen: Automate the pain out of your development environment. Boxen installs your dependencies so you can focus on getting things done.
Pivotal Lab's Workstation: A cookbook of recipes for an OSX workstation.
Thoughtbot's laptop focuses on getting a well-chosen standard set of tools to work on your Mac (you can see which ones in the script).
Boxen seems to be more for teams trying to build their own replicable custom development environment.
Related
I have a few questions about using Ruby on an OS X 10.11 El Capitan:
Do you think it is ok to modify Apple's built-in Ruby installation (as in installing or upgrading Gems), or should I install a separate ruby environment? (I had been modifying the built in one previously, but once I upgraded to El Capitan Apple undid all of my changes. I never had any problems with it before the upgrade, even when I updated the Gems that Apple included in to more recent versions. Yet I am still worried.)
I'm considering leaving Apple's built in Ruby alone and installing a separate one, leading me to my second question:
Everywhere I read on the internet, people recommend using a Ruby version manager (rbenv, RVM, and the like) to install a separate Ruby environment. I feel like it would be easier, cleaner, and more straightforward to simply use homebrew, since I use it already, to install a ruby to /usr/local. What would be some problems with using homebrew instead of a dedicated Ruby version manager? What are the advantages of using a version manager over homebrew?
Don't mess w/your system Ruby, your system needs to be stable and it's not necessary.
Homebrew isn't made to manage multiple versions of software. RVM (and others) and made to do exactly that. I currently have 6 rubies installed. I'd hate to have to manage that manually. RVM (or friends) is the way to go if you are installing Ruby on your host. People often go to the next level and use Vagrant instances to further isolate their development environment.
IMHO the most important reason to use a version manager is to be able to run multiple different versions of Ruby on the same machine e.g. to test gems with different versions or to run several (legacy and new) applications on the same development computer. Rbenv or RVM makes this easy, Homebrew doesn't support this...
I have a few Mac Minis and old Mac Pros we use as Jenkins slaves for automated testing.
Occasionally gems simply disappear and I have to re-install them. This is using the built-in Ruby from Mac OS Yosemite.
Why does this happen?
I use RVM on my personal Macbook Pro, and occasionally it autonomously decides to switch to a new Ruby version, so it makes sense that it won't have all my gems. When I switch back, the gems are gone again.
As for the slaves, they don't have RVM installed, and the outcome is the same.
Could this be caused by Mac OS updates?
The gems are not installed in a Jenkins workspace, I installed them before we installed the Jenkins agent.
The Macs are shared with the test-automation team who also ssh/sudo on them, but don't do anything in Ruby because their code is Java.
Could this be caused by mac OS updates ?
It could be caused by OS updates, and this is one of the big reasons you should not use the system Ruby for your development unless you're content with leaving it plain vanilla. Rightly so, Apple considers that Ruby theirs, and they can and will stomp on it with an update if it suits their purposes and you upgrade the OS.
Instead, at a minimum, install a separate Ruby from source or via Homebrew and consider that yours. Or, investigate using rbenv or RVM on the Jenkins boxes to manage your Rubies, which is what we do. That allows builds to use different Rubies and/or sets of gems and lets you fine-tune the Ruby environment on the Jenkins box to whatever the final-destination Ruby will be.
You say your personal RVM changes on its own? Unh-uh, can't happen on its own; SOMETHING told it to change. Don't attribute that stuff to voodoo or juju, something is making those things happen such as your environment variables changed or the .rvmrc file got stomped on. If your RVM configuration is correct it should be very stable; My rbenv and RVM setups have always been very solid unless I screwed them up.
Without dumps of your gem env or rvm info there's not a whole lot we can do to help you straighten it out. In general though, it sounds like you need to treat your Jenkins hosts like they are production boxes, change them very little, and separate your assets from the vendor's.
I often have use for software that requires compilation, on machines that don't have developer tools installed. Today I found something that I thought would simplify my life. Brew-pkg allows you to create installer packages of things that you already have installed on your system. I took it for a test spin by creating a tmux installer package. Before I knew it I had a an installer. What's more, it worked on a handful of test computers. So I went ahead and distributed the packaged to a number of other computers including some Mac OS 10.6 machines. Sadly, on these machines, tmux just reports Illegal instruction and then stops.
So, my question is twofold.
Is there something I don't understand about how binaries work that explains this behavior?
How can I create pkg installers that install and work on various Mac OS versions?
Confusedly,
Cory
I have some ruby scripts for end users that will be nice to have some GUI. Some of users use Windows, some Mac OS X (Snow Leopard, Lion). So i need some kind of cross-platform GUI that my users can easily install. For Windows where is built-in Tk and a number of gems that can be installed as easy as gem install wxRuby. But on MacOS i have some problems:
No built-in Tk due to 64-it nature of Snow Leopard+ and no easy way to install it.
qtRuby4 gem does not exist for Mac OS X at all.
gtk2 gem is native and fails to build on Mac OS X Snow Leopard+
wxruby gem install but will not work on 64-bit Snow Leopard+, scripts need to be executed manually in 32-bit mode.
Maybe someone can suggest some distribution / way to install GUI toolkit for ruby that will be easy to install for end users for both Windows and Mac OS X Snow Leopard / Lion? Or the wxRuby is the only way and i need to somehow make sure that end users execute scripts in 32-bit mode?
I haven't used it, but Shoes may fit the bill.
There was a Ruby GUI survey in 2008, which would need an update. Maybe it's still interesting though:
http://www.pressure.to/ruby_gui_survey/
IMHO from your list your best bet is wxRuby, sans the 32-bit limitation. An alternative way would be to wrap up your application as a lightweight web app using something like Sinatra, starting a server on localhost and telling the user where to go in the browser. That is if doing GUIs in JavaScript is your thing.
Ok, for now it seems that the easiest way will be to use Ruby-GNOME2. The instruction to configure ruby for OSX will be to install macports via standard .dmg installer and execute one command:
sudo -s "port selfupdate; port install ruby; gem install gtk2"
Of course installing something is not very user-friendly, but manual tinkering with 32-bit / 64-bit interpreter execution for wxRuby afraids me more. That will require either to modify end user system or to add some kind of bootstrapper into each script so it will check if executed on 64-bit macos and in such case relaunch itself in 32-bit interpreter.
I want to make a development server for Ruby. (I have done this for IIS and a LAMP set up, but am by no means proficient at it.) What will I need besides the actual server (which I already have)? And also any security issues? I know I could dev locally on my machine, but don't want to do that.
First off when doing ruby development the first thing to know is that it works best in a unix like environment, so mac os x, linux, solaris, bsd, etc...
Ruby libraries are distributed and packaged as gems. So you'll want to install ruby and install rubygems. Then from there on you use the gem command for installing ruby libraries.
I'm going to assume you're talking about doing web development with either ruby on rails 2.x or Merb 1.x. The two frameworks are merging in the next release and it'll be called Rails 3.0. So the answer here works for either one. I'm going to say Rails, but i mean Rails/Merb.
Rails development is done locally on your machine. So you'll need to install ruby and all the libraries you need locally. I know many people who use Windows end up using virtualization and running a linux environment for rails within their desktop windows box.
In development most people use an application server, Mongrel. In production the current standard is to use Apache 2 and Passenger.
With rails you're going to want to use source control. Most people today use git in the rails community, but it's possible to use subversion, perforce, or many other SCM's. To get your application from your source control to your staging and production systems, the rails community created an application called Capistrano. It handles deployments. You setup your server information, ssh keys, define access, and then you can release your application with a single command.
cap deploy
It's a pretty good system. Back several years ago now when i was working on odeo.com we had people using windows, linux, and mac's all for development with production deploys to debian linux. It wasn't intentional that our application be cross platform, it just worked out that way because we had people who wanted to add to it, including designers and biz types, who were on windows.
I highly recommend you check out http://guides.rubyonrails.com for more information.