Update: Val just released the packaging/update component... that + runtime should be all folks need to try plugems for themselves.
http://revolutiononrails.blogspot.com/2007/05/release-plugems-packaging.html On 5/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Our main reservation vis-a-vis the vendor everything approach is that > it makes for painful distribution when you have multiple teams and > multiple applications that share the same 'operating > environment' (i.e. colocated with a shared GEM_HOME). > > If you have a major security hole in shared dependency Foo that you've > backported to all of the major releases, you would need to hunt > through every app and replace the gem in question with the right gem > from based on release. Instead, we just build a gem for each backport, > install them on the gem server, and the 'shared environment' need only > update its repository and restart the apps. No need for a code deploy > on the applications themselves, which would cause the need to create a > maintenance branch on what might have been a short-lived release for > the sole purpose of updating a dependency micro. > > >From a development perspective, repositories have worked out great for > us as well. When I fix a major bug in a shared dependency, my > coworkers get the latest and greatest when they 'svn up; plugem > up' (which leverages gem update) in the morning--no wack SVN externals > (we started this journey in svn:external hell) or emails to links with > the latest gem. > > Platform-specific gems are also a dilemma in the vendor everything > approach (rmagick, hpricot, etc.)--compiling things at application > start seems somewhat unusual. We have both OSX developers and Windows > developers, so it's nice to just add hpricot to the manifest and let > the repository expose the different platform variations (as opposed to > bundling them all in vendor and adding even more logic to the plugin > stuff). > > Gem repositories just do such a good job at acting as a repository for > gems :-) > > I know this isn't the world that everyone is in (or wants to be in for > that matter), but I don't think it makes it much more difficult on the > KISS crowd (while it opens up a lot of doors for us fools that like to > overcomplicate things.) > > The catch is the need for the application manifest file to declare the > dependencies, but thats brings a lot of secondary value to the table > as well. You can use it to generate spec files to gemify apps (as we > do), guarantee the presence of required third-party gems at startup > time, etc. It's not so bad. > > More background on why we'd like to lobby for this approach in the > body and comments of : > > http://revolutiononrails.blogspot.com/2007/05/release-plugems-runtime.html > http://revolutiononrails.blogspot.com/2007/05/plugems-more-than-dependency-management.html > http://interblah.net/2007/5/2/plugems-enter-the-rails-addon-fray/comment/297#comment-297 > > Thoughts? > > Eddie > rails-trunk AT revolution.com > > On Apr 19, 10:54 pm, Josh Peek <[EMAIL PROTECTED]> wrote: > > Just trying to raise some awareness and discussion on a patch I > > recently posted. > > > > The idea of freezing gems in your rails app has been around for a long > > time. However there is no suggested convention to follow. Chris > > Wanstrath has suggested the directory "vendor/gems" to be use in his > > post "Vendor Everything" (http://errtheblog.com/post/2120). > > > > Once you set your path to this directory, everything works great. > > There is no code difference between loading gems from your local > > machine with rubygems or from the "vendor/gems" directory. > > > > If everyone is down with this convention, we should add a few things > > in rails to encourage it. > > > > 1. Make the "vendor/gems" directory when you run the rails command. > > 2. Add "vendor/gems" to the load path > > 3. Load tasks from "vendor/gems" (I don't really use this but Nic > > Williams finds it useful) > > 4. Add some rake tasks to help you freeze gems. > > > > Are there any other techniques out there that work well for you? Or > > does this sound like a delicious patch? > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
