mina-deploy / mina

Blazing fast deployer and server automation tool

Home Page:https://rubygems.org/gems/mina

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Could you add back set_default?

x-yuri opened this issue · comments

Now I've got to do as follows:

require 'mina/multistage'   # invokes stage file (e.g., config/deploy/production.rb), which sets rails_env
require 'mina/rails'   # sets rails_env
invoke ARGV.first if fetch(:all_stages).include?(ARGV.first)   # invoke stage file again to set rails_env again
puts fetch(:rails_env)

With set_default it could be this way:

require 'mina/multistage'   # invokes stage file (e.g., config/deploy/production.rb)
require 'mina/rails'   # set_default's rails_env
puts fetch(:rails_env)

Is there any reason not to add set_default? Or set rails_env this way:

set :rails_env, 'production' unless set?(:rails_env)

you can use environment variables to override mina variables:

https://github.com/mina-deploy/mina/blob/master/docs/how_mina_works.md#variables

You may specify additional variables in the KEY=value style, just like any other command line tools

Just like some Ruby tools do. Am I missing something? In Linux environment variables generally precede command name.

Is there any reason not to add set_default?

And most of all, how do environment variables address the issue? I'd like to store variables in stage files, but don't want to load stage file twice. It doesn't look good. And might actually break sometime.

Just like some Ruby tools do. Am I missing something? In Linux environment variables generally precede command name.

Yes, those are linux env variables and they can be before or after.

Is there any reason not to add set_default?

And most of all, how do environment variables address the issue? I'd like to store variables in stage files, but don't want to load stage file twice. It doesn't look good. And might actually break sometime.

Oh, i misread your issue, your issue is that mina/multistage and mina/rails set the same variable twice.
The fix for that is to require mina/multistage after the mina/rails which actually is the preferred way to do.

so

require 'mina/rails'   # set_default's rails_env
require 'mina/multistage'   # invokes stage file (e.g., config/deploy/production.rb)
puts fetch(:rails_env)

Could you please answer my question? Is there any reason not to add set_default?

And in any case, why don't we make mina/rails set rails__env only if unset? I can make a PR. This seems like a better solution:

set :rails_env, 'production' unless set?(:rails_env)

That way mina/multistage may always come first. No need for exceptions. It seems like a good idea for scripts (particularly, mina/rails) to take into account what was set before.