Robby on Rails: Managing Required Gems on Rails Projectsthoughts.sort_by{|t| t[:topic]}.collect tag:www.robbyonrails.com,2005:TypoTypo2008-03-27T01:46:16-04:00Robby Russellurn:uuid:1dad9e29-fb50-447c-802d-1a0f6109ff1d2008-03-26T22:27:00-04:002008-03-27T01:46:16-04:00Managing Required Gems on Rails Projects<p>We’re starting a new project and I’m finding myself adding things to the code base that we’ve done in the past… hence the last few posts. As we’re doing this, I’d like to highlight some of the little things that we do on each project to maintain some consistency and in that process reach out to the community for alternative approaches.</p>
<p>I’m intrigued by the <a href="http://errtheblog.com/posts/50-vendor-everything">vendor everything</a> concept, but we haven’t yet adopted this on any of our projects (yet).</p>
<p>What we have been doing is to maintain a <code>REQUIRED_GEMS</code> file in the root directory of our Rails application.</p>
<p>For example:</p>
<pre><code>
$ cat REQUIRED_GEMS
actionmailer
actionpack
actionwebservice
activerecord
activesupport
cgi_multipart_eof_fix
daemons
fastercsv
fastthread
feedtools
gem_plugin
image_science
mongrel
mongrel_cluster
mysql
rails
rake
RedCloth
Ruby-MemCache
soap4r
uuidtools
</code></pre>
<p>Everybody on the team (designers/developers) knows to look here to make sure they have everything installed when beginning to work on the application.</p>
<p>This has worked fairly well from project to project but since we’re starting a new project, I’m curious if anybody has some better ways to approach this. Should we look more seriously at the vendor everything approach or are there any alternative approaches?</p><p>We’re starting a new project and I’m finding myself adding things to the code base that we’ve done in the past… hence the last few posts. As we’re doing this, I’d like to highlight some of the little things that we do on each project to maintain some consistency and in that process reach out to the community for alternative approaches.</p>
<p>I’m intrigued by the <a href="http://errtheblog.com/posts/50-vendor-everything">vendor everything</a> concept, but we haven’t yet adopted this on any of our projects (yet).</p>
<p>What we have been doing is to maintain a <code>REQUIRED_GEMS</code> file in the root directory of our Rails application.</p>
<p>For example:</p>
<pre><code>
$ cat REQUIRED_GEMS
actionmailer
actionpack
actionwebservice
activerecord
activesupport
cgi_multipart_eof_fix
daemons
fastercsv
fastthread
feedtools
gem_plugin
image_science
mongrel
mongrel_cluster
mysql
rails
rake
RedCloth
Ruby-MemCache
soap4r
uuidtools
</code></pre>
<p>Everybody on the team (designers/developers) knows to look here to make sure they have everything installed when beginning to work on the application.</p>
<p>This has worked fairly well from project to project but since we’re starting a new project, I’m curious if anybody has some better ways to approach this. Should we look more seriously at the vendor everything approach or are there any alternative approaches?</p>