Alternative to #23638 log to STDOUT via env var

[schneems]

People who deploy to containers or other places where they might have some sort of a log wrapping service use stdout. With this change new rails apps can be configured to output to STDOUT via setting RAILS_LOG_TO_STDOUT to any value. This allows container images or services to set the value for all apps without having to modify configuration for each application. If an app wants to opt out, they can either delete from the env hash, or remove that configuration.

cc/ @rafaelfranca

[rafaelfranca]

huge 👎 to adding new env vars. We already have a lot and I really don't like the idea of environment variables. We have environment configurations files so lets use that. If people want to log to STDOUT they can just change the production.rb file.

[rafaelfranca]

Let me try again since I'm ditching your work without trying to understand. Why environment variable is better than have people changing their environment file? I know there are contained environments but when you make a choice to deploy to these environments could not you also change your application so it works in the environment?

[schneems]

It's only 1 more env var and it lets me kill https://rubygems.org/gems/rails_12factor 🙏. I promise no more env var pull requests for at least a year 😄

when you make a choice to deploy to these environments could not you also change your application so it works in the environment?

I want that "just works" (TM) experience with my apps. Most people don't care about the minutia of running on production, they want things to work out of the box. That is why we log to disk by default in production, instead of require a config change to do it. If I am an agency that is making new rails apps for different marketing sites every day then it is much easier for them to configure their environment once than to configure each new app every time. There's very few things that a container cares about to be able to run an app. The app has to know what port is available, the container needs to be able to capture logs, and in the case of Rails we want to be able to serve static files without needing an intermediate server such as nginx. These are the three configuration via environment variables experience that I am most interested in, and logging to STDOUT is the only one that doesn't work on master right now.

[rafaelfranca]

Can't that be done using a generator template? rails new -t https://heroku.com/rails_template my_app.

That application would work out of box and would also let heroku or any contained environment go crazy and set what they thing it is important for them.

I want that "just works" (TM) experience with my apps.

I know. I want that too and the current configuration file "just works".

If I am an agency that is making new rails apps for different marketing sites every day then it is much easier for them to configure their environment once than to configure each new app every time.

You are describing app generator template feature.

These are the three configuration via environment variables experience that I am most interested in, and logging to STDOUT is the only one that doesn't work on master right now.

In fact I was against the RAILS_SERVE_STATIC_FILES environment variable too. And if I recall correctly that was the "last environment variable that we need". After it we added RAILS_MAX_THREADS and now this.

If all we want is to new application "just works" in contained environments I'd go with a generator template.

[schneems]

I'll trade you RAILS_MAX_THREADS for this feature. My hope has always been to find some sane way to get rid of the rails_12factor gem. It only does two things log to STDOUT and flip a switch to enable static file service. Having to discover that rails_12factor gem or a template based solution is similar to discovering the corner of a piece of furniture in a dark room with your toe. The knowledge comes at a fairly painful cost.

Here's the original un-merged PR for adding static file service #17347 then eventually added by @chancancode in #18100.

To my knowledge the presence of the static file PR hasn't had any significant cost to Rails maintenance. People either use it or ignore it. I could make this PR a somewhat dense one liner, if we're concerned with line count. If your primary concern is my slowly replacing EVERY command with environment variables, I promise to not do that. I've promoted using env vars previously but don't think I've ever made a "this is the last one" statement before.

Terence previously tried to get STDOUT logging service and it was reverted 1a90550#commitcomment-2819166 though the reasons given are related to the presence or not of logging files. I don't think that is a good approach as it is too heavy handed. My other closed PR was an attempt at a "why not both" type solution which also appeared heavy handed. This PR is a pretty minimal, non-magical configuration addition. I can't imagine this causing any kind of maintenance burden.

I hear what you're saying about templates. It still feels like the wrong solution. It seems like a very high overhead for configuring one value. I don't see it as any better than the rails_12factor gem. It might be worse for our case since there is a standard way to see if there is a gem in your Gemfile.lock but not to introspect Rails config in a machine readable way, which is perhaps another discussion.

[rafaelfranca]

I'll sleep on it. I see your points too and they make sense.

[schneems]

Thanks for the extra consideration.

[schneems]

We talked about this in campfire. The change was deemed acceptable, merging in.