No middleware without touching RACK_ENV
normalperson at yhbt.net
Mon Jan 28 23:21:43 UTC 2013
"Lin Jen-Shin (godfat)" <godfat at godfat.org> wrote:
> On Sat, Jan 26, 2013 at 2:39 AM, Eric Wong <normalperson at yhbt.net> 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 :(
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
> 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.
More information about the mongrel-unicorn