Thanks for the response Jamis....I'll follow up if I can put something together that works well for us.
-John On Jun 3, 12:58 pm, Jamis Buck <[EMAIL PROTECTED]> wrote: > I like the idea of it, certainly, but I'm hesitant to pull something > like that into Capistrano itself. I'd strongly recommend that you > develop and release it as a third-party capistrano extension. If it > gains enough traction, we can look at pulling it into core later. > > - Jamis > > On Jun 3, 2008, at 10:46 AM, John Trupiano wrote: > > > > > 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 -~----------~----~----~----~------~----~------~--~---
