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 -~----------~----~----~----~------~----~------~--~---
