I suppose similar functionality to GemInstaller is now included in rails 2.1. That said, I can still see a need to expose this functionality remotely via Capistrano. Any thoughts on this? Or the other question I posed about auto-aborting a deployment if deploy:check fails? Also, any thoughts on how to cleanly link capistrano's concept of roles to the gems required in the environment files?
As an example, servers in my db role probably don't need any gems installed....in fact, they may not even need rubygems. Perhaps a rails patch adding this as an option to the new config.gem command? This feels a little dirty, as I don't think rails should really cater directly to capistrano like that. Perhaps the solution is to continue using Chad's geminstaller.yml concept, but then to simply add a patch to rails exposing an option to load the gems from this file and dynamically call config.gem for each gem present. This way, all of our gem definitions can be located in a single gems.yml file, and in here we can just add a 'roles' attribute to each gem definition. Capistrano will reference this when checking for and installing gems on remote servers, and rails will just ignore the option. I'm guess I'm starting to blur the line between server management and application management. Am I off-base in my thinking here? -John On Jun 3, 10:21 am, John Trupiano <[EMAIL PROTECTED]> wrote: > Hi Jamis, > > I was curious if you'd be interested in a patch that would expose an > option (e.g. :use_geminstaller) that would add as remote dependencies > each of the gems found in a geminstaller.yml file (Chad Wooley's > GemInstaller gem). Basically, if the option were set, deploy:check > would also read the geminstaller.yml file and parse the dependencies. > Furthermore, an additional task (e.g. :install_gems) could be exposed > to actually install each of the gems. > > Until now, one of the steps I've put into my deploy:update is a method > that runs Chad's geminstaller executable. However, this can slow down > deployment considerably, and might work nicely if I moved it out of > the standard deploy process. On this note, is there a way to > currently require that deploy:check is successful before actually > invoking a recipe? This would eliminate the need for the developer to > mindfully run deploy:check before trying to re-deploy (in the event > that perhaps the geminstaller.yml file has changed). > > Lastly, do you feel this would be more appropriate to just hack > directly into deploy:check, or should I push this into the > RemoteDependency class? > > btw, I see potential problems when deploying to multiple servers (i.e. > a db server, a web server, a load balancer, etc) in that you'd > probably want to require a distinct set of gems per role. However, I > imagine these issues could be worked out by exposing more > configuration options (either in geminstaller or capistrano). > > -John --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
