From: Matt Todd <chiology@gmail.com>
To: rack-devel@googlegroups.com
Subject: Re: ENV["RACK_ENV"] is not set on startup [rack/rack GH-11]
Date: Thu, 8 Apr 2010 07:23:06 -0400 [thread overview]
Message-ID: <m2i2a8d4a711004080423ne56fd5c8uef46edcfe571cfdf@mail.gmail.com> (raw)
In-Reply-To: <525E49F0-5E42-4040-8743-98D29A2DF781@gmail.com>
Oh man, you're right... how hadn't I seen that before? Anyways, that's
interesting... not sure how I feel about it.
Guess we can only carry a "pristine" idea so far before it gets
cumbersome/difficult/bothersome.
Matt
On Thu, Apr 8, 2010 at 4:46 AM, James Tucker <jftucker@gmail.com> wrote:
>
> 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.
>
>
--
Matt Todd
Highgroove Studios
www.highgroove.com
cell: 404-314-2612
blog: maraby.org
Scout - Web Monitoring and Reporting Software
www.scoutapp.com
prev parent reply other threads:[~2010-04-08 11:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-31 13:38 [GitHub] ENV["RACK_ENV"] is not set on startup [rack/rack GH-11] Christian Neukirchen
2010-03-31 13:58 ` Nicolás Sanguinetti
2010-03-31 14:12 ` James Tucker
2010-03-31 22:40 ` Joshua Peek
2010-04-01 7:16 ` Eric Wong
2010-04-01 8:21 ` Matt Todd
2010-04-01 8:49 ` James Tucker
2010-04-01 21:13 ` Eric Wong
2010-04-02 4:03 ` Matt Todd
2010-04-08 8:46 ` James Tucker
2010-04-08 11:23 ` Matt Todd [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://groups.google.com/group/rack-devel
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2i2a8d4a711004080423ne56fd5c8uef46edcfe571cfdf@mail.gmail.com \
--to=rack-devel@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).