How do I tell what env my code is running under?

[meltonian]

I'm new to the Rack party. I discovered Rack this last Friday and I've
logged some serious time in the last three days getting to know the
code base.

I'm working on something which requires the need to fork code based on
your environment (dev vs. production). Is there an easy way to
determine this? From what I can see, the env passed to call(env) has
some additional 'rack.xxx' variables but nothing about the env it's
running under.

Also, is 'deployment' the same as 'production' ala rails?

[Christian Neukirchen]

meltonian <gme...@gmail.com> writes:

> I'm new to the Rack party. I discovered Rack this last Friday and I've
> logged some serious time in the last three days getting to know the
> code base.
>
> I'm working on something which requires the need to fork code based on
> your environment (dev vs. production). Is there an easy way to
> determine this? From what I can see, the env passed to call(env) has
> some additional 'rack.xxx' variables but nothing about the env it's
> running under.

It is not stored. It probably should be. "rack.rackup.environment"?

> Also, is 'deployment' the same as 'production' ala rails?

Yes.

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

[meltonian]

That would be ideal.

It would also be super handy to have access to this outside the
request env.
Somewhere which can be accessed across all apps like: Rack::Rackup.env

Or, maybe even, Rack::Config as a separate module, for storing app
specific configurations.
Let me piece something together and submit a patch.


On Dec 23, 1:08 pm, Christian Neukirchen <chneukirc...@gmail.com>
wrote:

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

[Matt Todd]

I would lean away from concepts like app-specific configurations for Rack since it's not really intended (in my understanding of Rack's design) to have anything specific to application, and, instead, provide an agnostic, simplistic interface to several different layers of applications that don't collide....

Rack::Config would be kind of the opposite to this, I think.

However, I think something like the environment would be something that is environment-wide (hence the name) so I think the value being stored in the environment is actually preferred.

Just my $0.02.

Matt

--
Matt Todd
Highgroove Studios
www.highgroove.com
cell: 404-314-2612
blog: maraby.org

Scout - Web Monitoring and Reporting Software
www.scoutapp.com

[Ryan Tomayko]

On 12/23/08 3:26 PM, meltonian wrote:
> It would also be super handy to have access to this outside the
> request env.
> Somewhere which can be accessed across all apps like: Rack::Rackup.env
>
> Or, maybe even, Rack::Config as a separate module, for storing app
> specific configurations.
> Let me piece something together and submit a patch.

Thin sets ENV['RACK_ENV']. That seems like as good a place as any for
something like this.

Ryan

[Matt Todd]

Thin sets ENV['RACK_ENV']. That seems like as good a place as any for
something like this.

Sounds good to me.

[James Tucker]

On 23 Dec 2008, at 20:40, Matt Todd wrote:

Thin sets ENV['RACK_ENV']. That seems like as good a place as any for
something like this.

Sounds good to me.

I feel a bit evil to be disagreeing again, but could we keep this in the request env stack?

I know multi-app per process isn't that popular, but using a global prevents mixing up environments / setting them 'per request', or other formulas that might be useful in debugging on live / otherwise systems.

$0.02

[Matt Todd]

Isn't the concept of the ENV data that it's the global environment for the request?

The fact that it's modifiable argues against that, but I think that's just a curious mechanic of the flexibility and freedom of the implementation.

Matt

[Ezra Zygmuntowicz]

But ENV is global for the whole process. What if you want to run
multiple rack apps in the same process without them stepping on each
other? This will be more and more common in the future as we get more
true threraded VM's for ruby.

I think it would be better to be able to specificy the environment as
part of rack build when you setup a middleware chain? So you can set
them individually per app?

Thoughts?

-Ezra

Ezra Zygmuntowicz
e...@engineyard.com

[Matt Todd]

Sorry, not ENV, but the environment hash passed into #call.

Matt

[Greg Melton]

Just wondering if this made it into the 0.9.1 releases?

[Christian Neukirchen]

"Greg Melton" <gme...@gmail.com> writes:

> Just wondering if this made it into the 0.9.1 releases?

No. 0.9.1 is mere fixing of the bug.