rack-devel archive mirror (unofficial) https://groups.google.com/group/rack-devel
 help / color / mirror / Atom feed
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, 1 Apr 2010 04:21:03 -0400	[thread overview]
Message-ID: <s2z2a8d4a711004010121w99fdae8eo65ba3a8fe0ebc4fe@mail.gmail.com> (raw)
In-Reply-To: <20100401071650.GB30070@dcvr.yhbt.net>

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

  reply	other threads:[~2010-04-01  8:21 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 [this message]
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

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=s2z2a8d4a711004010121w99fdae8eo65ba3a8fe0ebc4fe@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).