"Lin Jen-Shin (godfat)" <[email protected]> wrote: > On Sat, Jan 26, 2013 at 2:39 AM, Eric Wong <[email protected]> wrote: > > Doesn't Rails favor RAILS_ENV over RACK_ENV? unicorn ignores RAILS_ENV > > (unicorn_rails respects RAILS_ENV, but unicorn_rails isn't recommended > > for modern (Rack-enabled) Rails) > > Yes, it is. But it would still look into RACK_ENV if RAILS_ENV is not > available. > One solution would be setting RAILS_ENV=development while setting > RACK_ENV=none. I don't really want to do this for several reasons: > > * It would be better to keep RAILS_ENV == RACK_ENV to avoid confusion. > * It might be tricky to make RAILS_ENV default to development while setting > RACK_ENV since Rails would be looking into it. So we need to make sure > that Rails is loaded and default to development and then we can setup > RACK_ENV to avoid messing up the original Rails default.
OK, I agree making RAILS_ENV==RACK_ENV in deployments is less confusing. (unicorn should continue NOT enforcing this internally, though) > > I'd imagine users wanting the same app-wide settings going between > > different application servers, too. > > Speaking to this, I might want to complain about the other severs :P > As far as I know, only if you use `rackup' would you get those middleware. > > That is, `unicorn' is compatible with `rackup'. That's a good thing. > But it seems to me that both `thin' and `puma' (and maybe including > others, I didn't check) would not do this if you use their command line > tools. They even have different options to enable Rack::CommonLogger. > > Actually this is also the reason why sometimes `thin' and `unicorn' > worked differently when people switching from Thin to Unicorn. > And you know a lot of people are using Thin in the first place, > thus sometimes blaming Unicorn works differently. > > I am not sure how many people are using `rackup', but according to > my observation, not too much. If people are using Sinatra directly, > eventually they would launch the server via Rack::Handler.get.run, > which does not try to wrap additional middleware as what `rackup' > would do if I read correctly. > > So I am not sure if a lot of people would be expecting this actually. > I used to use `rackup' a lot to get consistent behaviour, but it looks to > me not many people even know the existence of rackup :( *sigh* :< I kinda wish there was no default middleware, either. But it's too late to change unicorn defaults. I think your -N/--no-default-middleware patch can be accepted, then. after_app_load is more prone to user error/confusion, I think (I believe RAILS_ENV/RACK_ENV should be frozen for the lifetime of the process) > Last time I tried to setup SMTP for git send-email failed. > I'll try again next time. Thanks! Can you try send-email again with the --no-default-middleware patch? :) The git-send-email(1) manpage has several good examples for your email provider. There's also git-imap-send which you can use to stick email in your Drafts folder, but I've never needed/used it, though. _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
