Introduce APP_ENV and remove RACK_ENV

[dmathieu]

RACK_ENV should not be used with values other than development and deployment. Therefore, it can't be used to check for `production environment.

See http://www.hezmatt.org/~mpalmer/blog/2013/10/13/rack_env-its-not-for-you.html

In fact, it can even cause some issues if your app is using unicorn, as they're including internal rack middlewares relying on RACK_ENV to have the deployment value.
See https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L56-L79

Rack itself does that too.
https://github.com/rack/rack/blob/4e4ab39b0508aa3e59f5d7e53696ef6ae7c220ed/lib/rack/server.rb#L228

This removes using RACK_ENV, and replaces it with SINATRA_ENV.
Since it's a major changes, it should be merged in the Sinatra 2.0 branch. I'm not seeing anything of the kind, so feel free to stall this until there's discussion about it.

[gshutler]

I agree with the idea of this change but perhaps there's a middle ground as this would be a significant breaking change as it stands:

set :environment, (ENV['SINATRA_ENV'] || ENV['RACK_ENV'] || :development).to_sym

Then the use of RACK_ENV could be deprecated and checking it removed in the next major version.

[gshutler]

Sorry, I missed your note about this being for 2.0. Perhaps my suggestion would enable this to be merged to the main branch?

[dmathieu]

I think enabling SINATRA_ENV, with a deprecation message when falling back to RACK_ENV, and then entirely disabling it in 2.0 makes sense.

[zzak]

Sorry you are hitting this bug.. thank you for the thorough investigation! <3

[jeremy]

Changing to SINATRA_ENV is legit for its own sake. However, doing it response to this blog post's reimagination of RACK_ENV may be premature.

TL;DR: Nobody's been doing it wrong; RACK_ENV is the Rack app environment. Rack::Server had an -E environment but adopted RACK_ENV from server & framework usage.

Discussion on Rack @ rack/rack#831 (comment) and Rails @ rails/rails#19404 (comment)

[jeremy]

History:

• RACK_ENV introduced in Sinatra (33cbef5) in 2008, courtesy Thin (macournoyer/thin@1e90d63).
• RACK_ENV introduced in Rack (rack/rack@b433e48) in 2010 in response to established app, framework, and server convention.

[zzak]

@dmathieu Needs a rebase <3

[dmathieu]

Done 😸

[art-solopov]

😮 I didn't know this before! Apparently, my blog runs by pure coincidence.

[zzak]

@dmathieu How do you feel about this:

# warn if RACK_ENV is set, to recommend SINATRA_ENV here, then:
set :environment, (ENV['SINATRA_ENV'] || ENV['RACK_ENV'] || :development).to_sym

This would allow users to choose SINATRA_ENV or fallback to the RACK_ENV if available.

I don't think we can simply ignore RACK_ENV but make a suggestion to enlighten people about it's proper usage.

But maybe RACK_ENV is always set, somewhere, so this warning will get annoying.

/cc @gudmundur

[mperham]

All of these pieces (Rails, Sinatra, puma, thin, sidekiq, etc) are all application infrastructure processes. We want to determine what environment this application process is running in. Why not APP_ENV so we don't have RAILS_ENV, PUMA_ENV, SINATRA_ENV variables for every piece?

[dmathieu]

@zzak that works for me. I've updated my PR.
I don't mind using APP_ENV either.

[zzak]

One thing I'll add to the discussion regarding this is, APP_ENV only seems appropriate if everyone wasn't using Rack to begin with.

We might as well just use RACK_ENV properly since we can safely assume anyone using Sinatra is also, and intending to, use Rack as well.

But since I feel that ship has sailed, I'm ok with using APP_ENV if there aren't any objections. I guess it depends on whether other frameworks are willing to adopt it?

I don't mind being the first.

[mperham]

Happy to add it to sidekiq and I bet we could talk evanphx into adding it to puma. It should spread from there.

[gudmundur]

I'll make sure it lands in https://github.com/interagent/pliny as well.

[zzak]

@dmathieu Ok, lets change it to APP_ENV and see how it goes.

Worst case, we're ahead of the curve which never gains traction and we just introduce Yet Another Environment Variable to peoples apps. In which case, we do anyways if it was SINATRA_ENV, and still support RACK_ENV so I'm not of afraid of no 👻

[dmathieu]

LGTM. I've changed this PR to use APP_ENV instead of SINATRA_ENV.

[stefansundin]

The website still references RACK_ENV, can anyone update that? http://sinatrarb.com/configuration.html

[ioquatix]

Sorry to necro-bump this issue but after several years, have we actually reached any consensus or change on this issue?

[henrik]

@ioquatix I just came here from seeing the 2.0 release mentioning APP_ENV is now preferred, so it's listed there at any rate :) https://github.com/sinatra/sinatra/blob/master/CHANGELOG.md#200--2017-04-10

[mperham]

I've added support for APP_ENV in Sidekiq master.