How to easily package software that uses multiple gems into a debian installable packages?
You have a couple options
1) package your application as a gem using jeweler
By making it a gem, you can specify dependencies in the gemspec, so when it is installed
rubygems will automatically attempt to install the needed gems.
This is probably the easiest thing
2) run an apt-server and package your app for it. There are some instructions on running an
apt server on the ubuntu help pages.
Packaging your app is somewhat complicated looking, but boils down to:
writing install/uninstall etc scripts
writing config files
Get started with this doc on the ibm developerworks
Related
I switched recently to the Nix package manager instead of Homebrew for OS X.
Usually, I install it with rbenv like:
brew install rbenv
rbenv install 2.2.0
I am asking myself now how does one do it with Nix? I've heard Nix itself is a good enough package manager, so maybe I can get rid of rbenv for handling my ruby version?
When I install ruby via Nix
nix-env -i ruby
Even when OS X recognises it:
$ which ruby
/Users/USERNAME/.nix-profile/bin/ruby
I am still getting a Permission denied error when trying to:
gem install sass
Would you still recommend rbenv for handling ruby installations? I
know I could just chown the Nix folder, but I should own it anyway.
I've had similar experience using python with nix.
Generally the approach when using nix is NOT to:
Install a language specific package manager for some version of a language (gem, pip, ...)
Use that language specific package manager to install libraries
Instead the nix way (from what I've learned) to do things is:
Install all already packaged applications with nix
If you are developing an application, instead of installing the libraries your application depends on via nix (or gem), you define a nix expression that describes your applications dependencies and use it as a development environment. (I think the documentation should be improved in this matter.)
Generally don't install libraries on their own and manually refer to those in some third-party build process. (This works in some scenarios, as in compiled C/C++ libraries, where dependencies of the libraries are built into them via RPATHs. But this does not work well with e.g. python packages.) In the end what you really want is the application, not the library!
You can find some documentation on how to set up such environments in the official nixpkgs documentation, mostly covering Haskell at the moment, but Ruby should be similar.
you can found package of ruby by following
nix-env -qa ruby
and then it will shows list of ruby versions
nix-env -i ruby-2.1.0-p0
This will install ruby version then check it by ruby -v
I'm given a server without any root access and very limited access to do any stuff. And I'm trying to install ruby on that box. I have a look at Omnibus chef and it looks like they pack embedded-ruby inside the package. So, the server doesn't need ruby installed on that box. I'm trying to achieve the same thing. How can I package my own embedded ruby so I can deploy like a tarball to the box without any compiling or installing?
RVM supports installing pre-built binaries (RVM installs Rubies local to the user, no admin access required):
http://syntaxi.net/2012/12/21/installing-prebuilt-binaries-with-rvm/
It's a little different than just dumping a tarball on the machine, but it will setup paths and everything for you, so odds are it will actually work.
I consistently run into issues with gems not having the required libraries on a server. RMagick is one, and usually mysql2, which usually require installing the dev versions such as:
imagemagick libmagickcore-dev libmagickwand-dev
My question is, is there a better way to manage this? I'm using bundler and capistrano, so it would be great if somebody could point me in the right direction.
The big problem I can see is that distros will change from server to server, but if I had a task I could run which could check the existence of these required packages based on the Gemfile, that would be tremendously helpful. Is this possible?
You can extend section 'cap deploy:setup'. =And in this section run 'apt-get instal imagemagick libmagickcore-dev libmagickwand-dev'. But you user must have sudo access.
Also you can read this manual
I would like to provision a new Ubuntu 10.04 box with Ruby 1.9.2. I'm using Vagrant and Chef Solo to provision the box with everything else I need (e.g. Rails, Rake, MongoDB). The default Ruby version is 1.8.7.
Is there a way to install Ruby 1.9.2 as part of the Vagrant/Chef provisioning process?
I've read on the Chef website about using my own bootstrap template — possibly with knife — such as this one, but because I'm using Vagrant I'm not sure where to put this template — I don't have a chef-repo, a .chef directory or even any Chef stuff installed in /etc/chef.
First, a bit of context. Most Vagrant baseboxes install Ruby for use by Chef and Puppet, but the latest ones do this into /opt/ruby rather than using the system packages. They also add /opt/ruby/bin to the path, but at the end.
This VeeWee template shows how the 10.04 box is currently built: https://github.com/jedi4ever/veewee/blob/master/templates/ubuntu-10.04.3-server-i386/postinstall.sh
As for your question, their are several different contexts you might be trying to address, each with a different solution. Hopefully one of these will be what you're looking for.
Run Chef recipes with 1.9.2
You might be wanting to test running Chef recipes under 1.9.2 and you don't want 1.8.7 anywhere near your box. The best way of approaching this would be to create your own VeeWee template and build yourself a new basebox. You could modify the one linked above to compile 1.9.2 instead of 1.8.7 and follow the instructions on https://github.com/jedi4ever/veewee
Develop with Ruby 1.9.2
Probably more likely is that you want to hack on some Ruby code using 1.9.2. For this you just need to install Ruby and have the binaries on your path before the /opt/ruby entry. There are several ways of doing this:
Compile Ruby from scratch yourself
Use a package. The apt packages in lucid won't give you 1.9.2 so you can roll your own if you like. Or here's one I'm currently using https://github.com/garethr/packages/downloads
Use something like RVM http://beginrescueend.com/
All of these could be managed using a Chef recipe. I'd probably not go for the compile option, leaving either just a straight download and package resource or the following RVM cookbook might be handy http://community.opscode.com/cookbooks/rvm for RVM.
The *gem_binary* option on the package resource might also be useful here depending on how you want to ensure gems get installed for your new 1.9.2 Ruby (rather than the 1.8.7 in opt)
The goal of knife bootstrap is to get Chef installed on the target system so it can run Chef Client. The Vagrant baseboxes tend to already have Chef installed so unless you're doing something specific and want to run multiple versions of Chef I'd avoid this route. The built in Chef provisioners like http://vagrantup.com/docs/provisioners/chef_solo.html are a better bet.
I know the question is quite old and already answered, but I hope this still may be interesting for someone stumbling upon this question.
I've built a Github repo which intends to provide several configurations for building and provisioning a Vagrant box without requiring to write a provisioning recipe from scratch.
For example, using the currently provided configuration, you can build and provision a box with:
Ruby 1.9.2-p290, managed with rbenv and using Bundler for gems
PostgreSQL 8.4
MongoDB
Here is an introduction article on my blog.
Since this almost match the request, I felt it was worth adding this late answer :)
Here's the recipe i'm using to install Ruby 1.9.2
package "libffi5" do
action :install
provider Chef::Provider::Package::Apt
end
package "ruby-1.9.2" do
action :install
source "/tmp/vagrant-chef/cookbooks-0/ruby-1.9.2/files/default/ruby-1.9.2-p290_i386.deb"
provider Chef::Provider::Package::Dpkg
end
Upon upgrading from a MB to a new MBP, Apple's migration assistant didn't move my gems.
I'm installing rubygems via macports this time, hoping to avoid this upon next upgrade.
Are there any pitfalls I should be aware of?
If you want your gems installed in your home directory (which should copy over during a transfer, and, as a side benefit, will let you run gem install as yourself, rather than root), set the gemhome: key to a path in your home directory in your ~/.gemrc.
Where were your gems installed? The migration assistant only moves files in certain areas; I'm not sure if it copies files from places like /usr/local or /opt/local, you may have to do that manually (in which case, you can just copy the entire tree over to your new machine).
That said, you shouldn't have a problem installing gems using the version of RubyGems installed by MacPorts.
Installing a package manager via a package manager seems like it should be wrong.
Assuming you are not going to use the system ruby, and will only be using ruby installed via MacPorts; it should not be a problem.
If you plan on using gems with system ruby, you might have problems when Apple upgrades the system version of ruby, unless you are installing your gems in /Library/Ruby/Gems/
I'm going to assume you can just copy the gems to /Library/Ruby/Gems/1.8/gems from /opt/local/lib/ruby/gems but I wouldn't count on it working 100% with every gem.
The migration assistant doesn't move a lot of unix level stuff. This will be true of the macports installed gems as well (which typically live in /opt/local/lib/ruby/gems).
I use macports gem, and this generally works fine with the macports ruby. Be sure you know which ruby executable your shell ends up using, and perhaps use symlinks to control it specifically. I prefer using the macports version so that I'm not beholden to Apple's update schedule. Sadly macports iteself is somewhat inferior to package managers offered on bsd/linux distributions.
I would say don't use MacPorts. People that use their operating systems version of RubyGems often end up with an out of date gem version and then run into problems when they try to update their version of rubygems. Installing Rubygems from source is easy, and it's not hard to install gems when you get a new machine, I mean how often does that really happen????
I just installed ruby 1.8.7 with macport and when I launch scripts with gems, it complains that it doesn't know them.
Anyway to add cleanly the gems in the path of my macport ruby?
Gam
PS: I installed the gems via system gem
What no one mentioned rvm?
Use rvm to manage all of your ruby issues - seriously!