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

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

[Christian Neukirchen]

> Subject: [GitHub] ENV["RACK_ENV"] is not set on startup [rack/rack GH-11]
> 
> ENV["RACK_ENV"] is not set by rackup on startup, meanwhile at least
> Passenger, Thin and Unicorn pass this to apps. Besides that Sinatra
> and Merb use it to set their environment.  You can see the discussion
> about that in the Unicorn list:
> http://www.mail-archive.com/mongrel-unicorn@rubyforge.org/msg00123.html

> The patch to fix it here:
> http://github.com/tundraghost/rack/commit/90e9dfedf454a1491d97ab1d145cd105fdb1c216

Discuss.

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

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

[Nicolás Sanguinetti]

On Wed, Mar 31, 2010 at 10:38 AM, Christian Neukirchen
<chneukirchen@gmail.com> wrote:
>
>> Subject: [GitHub] ENV["RACK_ENV"] is not set on startup [rack/rack GH-11]
>>
>> ENV["RACK_ENV"] is not set by rackup on startup, meanwhile at least
>> Passenger, Thin and Unicorn pass this to apps. Besides that Sinatra
>> and Merb use it to set their environment.  You can see the discussion
>> about that in the Unicorn list:
>> http://www.mail-archive.com/mongrel-unicorn@rubyforge.org/msg00123.html
>
>> The patch to fix it here:
>> http://github.com/tundraghost/rack/commit/90e9dfedf454a1491d97ab1d145cd105fdb1c216
>
> Discuss.

Everyone standarized on using ENV["RACK_ENV"], so I don't see a
problem in doing it in core.

> --
> Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org
>
>
> --
> To unsubscribe, reply using "remove me" as the subject.
>

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

[James Tucker]

On 31 Mar 2010, at 14:38, Christian Neukirchen wrote:

> 
>> Subject: [GitHub] ENV["RACK_ENV"] is not set on startup [rack/rack GH-11]
>> 
>> ENV["RACK_ENV"] is not set by rackup on startup, meanwhile at least
>> Passenger, Thin and Unicorn pass this to apps. Besides that Sinatra
>> and Merb use it to set their environment.  You can see the discussion
>> about that in the Unicorn list:
>> http://www.mail-archive.com/mongrel-unicorn@rubyforge.org/msg00123.html
> 
>> The patch to fix it here:
>> http://github.com/tundraghost/rack/commit/90e9dfedf454a1491d97ab1d145cd105fdb1c216
> 
> Discuss.

+1, almost every single framework uses this notion, I think we should have it in the spec.

The possible disparity here is that we use "deployment" and "none" traditionally (with Yehudas Rack::Server deprecating "none" to be implicit instead). I think the best option is to map "production" to "deployment" for the time being, and maybe look at deprecating "deployment" in say, a year, if at all (don't really see why it needs to be removed tbh, other than neatness).

I would argue that an ENV var should be the default unless the argument is explicitly specified, so that patch may be insufficient.

If we get more +1s, I'll import and fixup, as I've been poking Rack::Server recently.

> 
> -- 
> Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org
> 
> 
> -- 
> To unsubscribe, reply using "remove me" as the subject.

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

[Joshua Peek]

On Mar 31, 8:38 am, Christian Neukirchen <chneukirc...@gmail.com>
wrote:
> > Subject: [GitHub] ENV["RACK_ENV"] is not set on startup [rack/rack GH-11]
>
> > ENV["RACK_ENV"] is not set by rackup on startup, meanwhile at least
> > Passenger, Thin and Unicorn pass this to apps. Besides that Sinatra
> > and Merb use it to set their environment.  You can see the discussion
> > about that in the Unicorn list:
> > http://www.mail-archive.com/mongrel-unic...@rubyforge.org/msg00123.html
> > The patch to fix it here:
> >http://github.com/tundraghost/rack/commit/90e9dfedf454a1491d97ab1d145...

+1 I changed Rails to prefer RACK_ENV over RAILS_ENV a while back.

Can we put this convention in "The SPEC"?

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

[Eric Wong]

James Tucker wrote:
> The possible disparity here is that we use "deployment" and "none"
> traditionally (with Yehudas Rack::Server deprecating "none" to be
> implicit instead). I think the best option is to map "production" to
> "deployment" for the time being, and maybe look at deprecating
> "deployment" in say, a year, if at all (don't really see why it needs
> to be removed tbh, other than neatness).

Joshua Peek <josh@joshpeek.com> wrote:
> +1 I changed Rails to prefer RACK_ENV over RAILS_ENV a while back.

What happens when Rails sees "none" or an empty value?

I've always preferred to start Rack with "none"/empty since I didn't
like the Rack::CommonLogger defaulting to $stderr which I believe should
be reserved for more critical messages.  I also prefer Clogger instead
of CommonLogger for access logs.

With RACK_ENV != RAILS_ENV, it was easy to deploy a Rails app without
the RACK_ENV=deployment defaults (which I don't want) conflicting
with the RAILS_ENV=production defaults (which I do want).   I guess
those apps will have to be reconfigured to use RAILS_ENV=none (or
RAILS_ENV=something_rack_will_never_understand :)

-- 
Eric Wong


-- 
To unsubscribe, reply using "remove me" as the subject.

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

[Matt Todd]

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.

Thoughts?

Matt



On Thu, Apr 1, 2010 at 3:16 AM, Eric Wong <normalperson@yhbt.net> wrote:
> James Tucker wrote:
>> The possible disparity here is that we use "deployment" and "none"
>> traditionally (with Yehudas Rack::Server deprecating "none" to be
>> implicit instead). I think the best option is to map "production" to
>> "deployment" for the time being, and maybe look at deprecating
>> "deployment" in say, a year, if at all (don't really see why it needs
>> to be removed tbh, other than neatness).
>
> Joshua Peek <josh@joshpeek.com> wrote:
>> +1 I changed Rails to prefer RACK_ENV over RAILS_ENV a while back.
>
> What happens when Rails sees "none" or an empty value?
>
> I've always preferred to start Rack with "none"/empty since I didn't
> like the Rack::CommonLogger defaulting to $stderr which I believe should
> be reserved for more critical messages.  I also prefer Clogger instead
> of CommonLogger for access logs.
>
> With RACK_ENV != RAILS_ENV, it was easy to deploy a Rails app without
> the RACK_ENV=deployment defaults (which I don't want) conflicting
> with the RAILS_ENV=production defaults (which I do want).   I guess
> those apps will have to be reconfigured to use RAILS_ENV=none (or
> RAILS_ENV=something_rack_will_never_understand :)
>
> --
> Eric Wong
>
>
> --
> 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

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

[James Tucker]

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.

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.



-- 
To unsubscribe, reply using "remove me" as the subject.

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

[Eric Wong]

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.

> 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.

If people want a request logger, they can configure Rack::CommonLogger,
Clogger or whatever else in config.ru.

-- 
Eric Wong


-- 
To unsubscribe, reply using "remove me" as the subject.

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

[Matt Todd]

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.

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.

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

[James Tucker]

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.

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

[Matt Todd]

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