No middleware without touching RACK_ENV
normalperson at yhbt.net
Fri Jan 25 18:39:59 UTC 2013
"Lin Jen-Shin (godfat)" <godfat at godfat.org> wrote:
> This might be a bit silly, but finally I decided to bring this up.
> We're running a Rails app along with another Rack app in
> the same config.ru, and what I want to do is telling Unicorn
> that we don't want any middleware which Unicorn might
> insert with RACK_ENV=development and RACK_ENV=
> deployment, because we're adding Rack::CommonLogger
> and other middleware by ourselves, while we're using
> RACK_ENV=development for Rails when developing.
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)
> That is, we want to use RACK_ENV=development for Rails
> because that's how it used to be, but we also don't want
> those additional middleware got inserted automatically.
> This has no problem with RACK_ENV=production.
Is there a benefit which RACK_ENV=development gives you for Rails
that RAILS_ENV=development does not give you?
Fwiw, the times I worked on Rails, I used customized dev environments
anyways, so I would use RAILS_ENV=dev_local or RAILS_ENV=dev_$NETWORK
for switching between a localhost-only vs networked setup.
> I know this is somehow a spec from Rack, but I guess I
> don't like this behaviour. One workaround would be
> providing a `after_app_load' hook, and we add this to
> the bottom of config.ru:
> ENV['RACK_ENV_ORIGINAL'] = ENV['RACK_ENV']
> ENV['RACK_ENV'] = 'none'
> and add this to the unicorn configuration file:
> after_app_load do |_|
> ENV['RACK_ENV'] = ENV['RACK_ENV_ORIGINAL']
> This is probably a stupid hack, but I wonder if after_app_load
> hook would be useful for other cases?
I don't see how this hook has benefits over putting this in config.ru
(or somewhere else in your app, since your app is already loaded...)
I'd imagine users wanting the same app-wide settings going between
different application servers, too.
> Or if we could have an option to turn off this Rack behaviour
> simulation, like:
> default_middleware false
> That might be more straightforward for what we want. Oh but
> it seems it's not that easy to add this. What about an option
> for unicorn?
> unicorn -E development -N
> unicorn -E development --no-default-middleware
I'm against adding more command-line or config options, especially
around loading middleware. RACK_ENV is already a source of confusion,
and Rails also has/(or had?) it's own middleware loading scheme
independent of config.ru.
> This would need to be applied to `rainbows' and `zbatery', too,
> though. Patches below for consideration:
> (Sorry if Gmail messed the format up, but from last time
> I tried, it doesn't accept attachments :( What's the best way?
> Links to raw patches?)
git format-patch + git send-email is the recommended way if your
mail client cannot be taught to leave formatting alone. Also this
is easy for sending multiple patches in the same thread.
git format-patch --stdout with a good mail client which will not wrap
messages is also great (especially for single patches).
Attachments (generated using git format-patch) for text/x-diff should be
accepted by Mailman. Attached patches are a last resort, I prefer
inline patches since I can quote/reply to them inline.
(same patch submission guidelines as git or Linux kernel)
> commit 95de5abf38a81a76af15476d4705713d2d644664
> Author: Lin Jen-Shin <godfat at godfat.org>
> Date: Fri Jan 25 18:18:21 2013 +0800
> Add `after_app_load' hook.
> The hook would be called right after application is loaded.
Commit messages should explain why a change is made/needed, not just
what it does.
More information about the mongrel-unicorn