Re: ENV["RACK_ENV"] is not set on startup [rack/rack GH-11]

[James Tucker <jftucker@gmail.com>]

On 2 Apr 2010, at 05:03, Matt Todd wrote:

> On Thu, Apr 1, 2010 at 5:13 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> James Tucker <jftucker@gmail.com> wrote:
>>> On 1 Apr 2010, at 09:21, Matt Todd wrote:
>>>> I'm not a fan of --env/:env in general, specifically taking issue with
>>>> implicitly modifying the middleware stack.
>>>> 
>>>> Because of this, I'm actually quite happy with the fact that
>>>> ENV['RACK_ENV'] isn't set when --env/:env is set.
>>>> 
>>>> I'd much rather this feature go away and let handling environments be
>>>> left up to the user.
>>>> 
>>>> More specifically:
>>>> * --env/:env should default to "development"
>>>> * --env/:env should set ENV['RACK_ENV']
>>>> * --end/:env should have no other affect
>>>> * applications/frameworks should adjust their environments according
>>>> to ENV['RACK_ENV'] as they see fit
>>>> 
>>>> I'm aware that this is mostly done to ease development and lower the
>>>> barrier of entry, which I'm not opposed to doing, but I think there
>>>> are other, better ways we can explore such as a separate
>>>> feature/option, perhaps only in rackup, that can enable these
>>>> middleware.
>>> 
>>> Rackup wants a logger mostly. I'm actually wondering if rackup wants a
>>> logger in all environments (not --envs) apart from CGI. We're never
>>> going to please everyone on this front, but maybe we need a way for
>>> rackup to turn off the default logger middleware separately to the
>>> --env setting.
>>> 
>>> --env development also has one other significantly relevant action,
>>> and that is to add Rack::Lint to the middleware stack in order to
>>> validate conformance to http and rack specs. I feel this should stay,
>>> regardless of other changes.
>>> 
>>> I propose then, that we modify the logger middleware setup to be
>>> affected by another argument, and that --env development adds
>>> Rack::Lint, any other --env does not modify the middleware stack at
>>> all.
>> 
>> Yes.  Lint is special.  It is important for development and should be
>> easily toggleable between different environments.  Heck, I wouldn't mind
>> a version that adds Lint between every part of the middleware stack,
>> even.  That would of course be a pain to configure by hand.
> 
> Ah, yeah, I see the value of that.
> 
> Maybe there's another solution besides Lint just being a middleware?
> Perhaps a Lintified response? Not saying the middleware is bad, just
> looking at our options.
> 
>>> This should be compatible with Rails envs, and also satisfy Erics
>>> desires. We can also then deprecate the unusual "deployment"
>>> environment which seems to be unique to rack.
>> 
>> I prefer Matt's approach to not do any middleware changes to go with
>> RACK_ENV (except Lint, above).
>> 
>> Extra command-line options that try to do the same thing as editing
>> config.ru make things more confusing than necessary.  I was not happy
>> with Rails inventing their own middleware configuration, either.

I must point you at the Handler implementations in core, most of which attach one or two middlewares to every app before attaching them to the server...

> 
> Agreed, agreed, and agreed. Lint is acceptable, but I think there
> shouldn't be any other side effects by setting the environment other
> than making sure ENV['RACK_ENV'] is set, imo. To be clear, I think
> that we are just making it easy for others to utilize this feature,
> but if it was taken out of Rack altogether, nothing should change but
> give frameworks a little more work.
> 
>> If people want a request logger, they can configure Rack::CommonLogger,
>> Clogger or whatever else in config.ru.
> 
> Agreed.
> 
> 
> -- 
> Matt Todd
> Highgroove Studios
> www.highgroove.com
> cell: 404-314-2612
> blog: maraby.org
> 
> Scout - Web Monitoring and Reporting Software
> www.scoutapp.com
> 
> 
> -- 
> To unsubscribe, reply using "remove me" as the subject.