I think it's a difference in philosophy. As a Unix admin, I see the value in setting a system-wide script on the server. After all, I might have mongrel_cluster and nginx installed, or I might have Apache and mod_rails -- as the admin, that's my choice, and the app developer not only doesn't have any say in it, they shouldn't have to think about it.
However, it's pretty clear that the Rails philosohpy is pretty much exactly the opposite -- the plugin system seems designed to ensure that absolutely everything to do with running the app is bundled up in the app itself. It's the moral equivalent of static linking -- the assumption is that you can't trust the remote host to have things setup properly, but with plugits, you don't have to. Capistrano seems to be driven by the same philosophy -- the entire app is distributed everywhere, and all the configuration is included with the app, in such a way that, in theory, you can deploy the same way to any remote host. I'm not going to actually state a preference, just pointing out where I think the disconnect is. On Thu, May 15, 2008 at 9:10 AM, Jamis Buck <[EMAIL PROTECTED]> wrote: > I disagree. You've certainly described *another* way to do it, but if it > means people have to actually set up those scripts themselves, your way > means additional (potentially confusing) setup is required for people who > want to use Capistrano, and that's what I'd like to avoid. > > What I'd love (pie in the sky, here) is for someone to install Capistrano, > and have everything they need right there. I think the deprec stuff is a > good example of that--a bunch of capistrano tasks that help you go from zero > to deploy using only Capistrano. I don't think Capistrano needs to ship with > a complete solution like deprec, especially it would need to understand all > the different server platforms, and that would get ridiculously complex (I > believe). > > Now, maybe the "right" way would be for deploy:setup to push the desired > web-start/web-stop/etc. script to each server, but from the user's > perspective that's transparent. In their deploy.rb, they've added a variable > or variables indicating which configuration they want, and they don't care > how it's implemented under the covers. The deploy.rb (or Capfile) is their > "recipe" for deployment, and should ideally be the centralized place where > they describe how it is configured. > > - Jamis > > > On May 15, 2008, at 3:39 AM, Neil Wilson wrote: > > >> That's not the way to do it. The way to approach it is to abstract the >> 'start', 'stop' process on the *server* not the client. >> >> That way you install a set of server scripts that conform to a >> standard interface and they depend upon the application/web/database >> layer you have installed on the server. >> >> Your client then simply calls 'web-start' and the right thing happens >> on each server depending upon which equipment you have installed. You >> can probably even have a mix of mongrels and passengers if you want. >> >> The client shouldn't care what is installed on the servers. It just >> needs a standard interface to work to. >> >> On 14 May, 22:34, Tom Copeland <[EMAIL PROTECTED]> wrote: >> >>> "set :application_container, :modrails" or something like that. That's >>> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
