Some thoughts

[Erik Dahlstrand]

1. Running rake inploy:remote:setup

I think things must happen in a different order. First git clone, then
copy sample files, then it should stop so that I can connect to the
remote server and edit my deploy.rb and database.yml, which will
contain only sample data. After that the script can continue.

Or am I missing something? You don't check in real usernames,
passwords etc. in the sample files do you?


2. gems:install fails if no development environment exists in
database.yml. I think it should be enough to include a production
environment in database.yml on production servers.

Inploy => rake gems:install
rake aborted!
development database is not configured

Maybe:
def install_gems
rake "gems:install RAILS_ENV=production"
end


Kind regards, Erik

[Diego Carrion]

Hi Erik,

About the second point, I do totally agree, do you want to make a
patch and pull a request?

About the first point, I'm not sure about what I think is the best
way. When working in private projects I don't usually have a
database.yml.sample but when working in public projects I do, as in
Signal.

In this case, the production environment is configured to work with
sqlite so Inploy dont fail but if you want to use another database
(recommended) then you have to connect to the server, edit the
database.yml file and run migrations.

I think this way demands two steps, as the recommended way to Inploy
will demand, too (edit the files and continue).

But I got an idea, what about making this configurable?

We can configure the deploy.rb something like this:

deploy.stop_after_copying_files = true # default false

or call Inploy like this:

rake inploy:remote:setup stop_after_copying_files=true

What do you think?

On Nov 10, 11:51 am, Erik Dahlstrand <erik.dahlstr...@gmail.com>
wrote:

[Douglas Campos]

> deploy.stop_after_copying_files = true # default false
>
> or call Inploy like this:
>
> rake inploy:remote:setup stop_after_copying_files=true
>
> What do you think?

IMO, the deploy.rb (sample) should never be copied by
inploy:remote:setup, as we need to alter it locally only. For me is
good practice to NEVER edit files on the target machine = less
error-prone in production

--
Douglas Campos (qmx)
+55 11 7626 5959

[Erik Dahlstrand]

> About the second point, I do totally agree, do you want to make a
> patch and pull a request?

Sure

> What do you think?

I'll guess it's about personal taste. I would prefer that each time,
one or more .sample files are copied, the user gets prompted e.g.

$ New sample files copied ['file1.rb', 'file2.yml']. You now have the
opportunity to login to ['server_name1'] and make necessary changes.
Press enter to continue...


/Erik

[Diego Carrion]

Will it annoy too much if were an attribute from deploy? like

deploy.stop_after_copying_files = true # default false

The problem with setting this as default is that is not that useful for some people, I think most people will not need this.

--
Diego Carrion
http://www.diegocarrion.com
http://www.mouseoverstudio.com/blog/
http://www.twitter.com/dcrec1
http://www.workingwithrails.com/person/13580-diego-carrion

[Erik Dahlstrand]

Of course I can only speak for my personal needs. I would never commit
any database credentials in the sample file. I think the basic idea
with a sample file is that it should contain... sample data. So I
definitely need to do those one-time-edits on the production server
manually. If inploy could remind me of that it would be great. I do
believe most of the users will only see this prompt once, and that is
when deploying for the first time. Hit enter to continue and it will
never bother you again...

Just my 1/50th of a dollar.

On 10 Nov, 20:46, Diego Carrion <dc.r...@gmail.com> wrote:
> Will it annoy too much if were an attribute from deploy? like
>
> deploy.stop_after_copying_files = true # default false
>
> The problem with setting this as default is that is not that useful for some
> people, I think most people will not need this.
>
> On Tue, Nov 10, 2009 at 1:35 PM, Erik Dahlstrand

> <erik.dahlstr...@gmail.com>wrote: