I can think of a few things that are in the general area or cut across the problem you're solving here, but not anything exactly like it.
Bundler and Isolate work at the level of single projects or applications, so that's not quite what you're doing here.
Rvm provides gemsets, and the global gemset is closer to what Heist does. You can fill it with items that get installed automatically when you install any new Ruby interpreter. But I'm not sure that you can use it to automate installation of multiple versions of one gem (as you show with redis in your example). (You can also export and import gemsets which solves some of the pain you describe with moving from server A to server B.)
What's the common use-case for transplanting lists of gems from one box to another in a non project-specific way (which would be handled via gemcutter).
What it basically does is to analyse your system, create a list of packages and files, save it in a git repository and allows you to export it to various different formats like shell script or puppet or chef.
Btw. this is IMHO a really big deal. Not only can you clone your environment easily, but it helps you to create a managed environment as you have at least a starting point to create your puppet manifests/chef recipes or at least shell scripts. And as it uses git you can easily use it to create distributed configuration backups of your systems. Oh and as the default output format is JSON you can start to create webservices showing the state of your servers/create a more convenient overview about your systems.
7 comments
[ 2.8 ms ] story [ 31.8 ms ] threadI can think of a few things that are in the general area or cut across the problem you're solving here, but not anything exactly like it.
Bundler and Isolate work at the level of single projects or applications, so that's not quite what you're doing here.
Rvm provides gemsets, and the global gemset is closer to what Heist does. You can fill it with items that get installed automatically when you install any new Ruby interpreter. But I'm not sure that you can use it to automate installation of multiple versions of one gem (as you show with redis in your example). (You can also export and import gemsets which solves some of the pain you describe with moving from server A to server B.)
Gem.loaded_specs.map{|n,s| "gem install #{n} --version=#{s.version}"} * "\n"
What's the common use-case for transplanting lists of gems from one box to another in a non project-specific way (which would be handled via gemcutter).
A more general approach which also covers python/php modules as well as system packages, configuration files, installed software on /usr/local , .. is blueprint https://github.com/devstructure/blueprint / http://devstructure.com/
What it basically does is to analyse your system, create a list of packages and files, save it in a git repository and allows you to export it to various different formats like shell script or puppet or chef.
Btw. this is IMHO a really big deal. Not only can you clone your environment easily, but it helps you to create a managed environment as you have at least a starting point to create your puppet manifests/chef recipes or at least shell scripts. And as it uses git you can easily use it to create distributed configuration backups of your systems. Oh and as the default output format is JSON you can start to create webservices showing the state of your servers/create a more convenient overview about your systems.