Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Parse yell.yml with ERB first / Make the :symlink option default to 'true'. #9

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
3 participants
Contributor

nengxu commented Oct 22, 2012

I usually add this ERB block at the end of every yml config file to allow each developer to override the config using her own local copy, without interfering with the version committed into git:

override the above with local settings from config/private/yell.yml

<%=
rails_root = Rails.root rescue (File.dirname(FILE) + '/..')
file = File.join(rails_root, "config", "private", "yell.yml")
IO.read(file) if File.exist?(file)
%>

Contributor

nengxu commented Oct 22, 2012

Another case of showing the benefit of this feature:

# separate info level messages into the legacy Rails log file
- :datefile:
    :level: 'info'
    :filename: 'log/<%= Rails.env rescue "development" %>.log'
    :symlink: true
Contributor

nengxu commented Oct 22, 2012

I don't know why github automatically added the other commit into this pull request. I originally wanted to open another pull request for it. So you can ignore the "Make the :symlink option default to 'true'." commit for this pull request. Thanks.

Contributor

nengxu commented Oct 22, 2012

Github doesn't allow me to create another pull request for the "Make the :symlink option default to 'true'." commit. Is the pull request branch-based, not commit-based? So I have to combine it here.

I use yell-rails gem to replace the legacy Rails logger with Yell (yeah!). However, if the datefile adapter is not using the :symlink option, an error will be thrown:
railties-3.2.3/lib/rails/rack/log_tailer.rb:8:in `size': No such file or directory - log/development.log (Errno::ENOENT)

The best way to handle that would be to add the :symlink option to yell.yml, as shown an above comment:
#9 (comment)

However, this option did not take effect. Possibly related to yell-rails not supporting this option?

So I adopted the least-resistance way, just set the :symlink option default to true as in the commit. This also makes sense for most real use cases, IMHO.

Owner

rudionrails commented Oct 23, 2012

@nengxu Thanks for the changes. I'll take the changes for the ERB stuff, but will not take the second commit. Firstly, because It breaks tests ;-) Secondly, because it kinda belongs more into the yell-rails gem. If you want, change the yell.yml template there to enable symlink: true by default and make another pull-request for the yell-rails gem.

One more thing, would you please amend your first commit to include require 'erb' at the top of the file for correctness sake? Force push your branch into your master and I'll pick the commit :-)

Contributor

nengxu commented Oct 23, 2012

I've fixed the tests, and added the 'require' as you required (pun ;).
How to test the robustness of our tests? Tests are meant to be
broken ;-)

About :symlink, it should not be delegated to yell-rails gem. Yell can
be used outside of Rails, no need for the yell-rails gem, right?

In real life, no developer would prefer to type "tail -fn300
log/development.20121023.log" today, and remember to change day,
month, year as time goes by. They will prefer to only type and
remember "tail -fn300 log/development.log", right?

By setting :symlink = true by default, Yell keeps a consistent API to
the legacy Rails logger: log/development.log, etc.

So please adopt the :symlink change too. Or you may ask other users'
opinions. Thanks.

On Tue, 23 Oct 2012 05:05:38 -0700
Rudolf Schmidt notifications@github.com wrote:

@nengxu Thanks for the changes. I'll take the changes for the ERB
stuff, but will not take the second commit. Firstly, because It
breaks tests ;-) Secondly, because it kinda belongs more into the
yell-rails gem. If you want, change the yell.yml template there to
enable symlink: true by default and make another pull-request for
the yell-rails gem.

One more thing, would you please amend your first commit to include
require 'erb' at the top of the file for correctness sake? Force
push your branch into your master and I'll pick the commit :-)


Reply to this email directly or view it on GitHub:
#9 (comment)

Owner

rudionrails commented Oct 24, 2012

OK, so I've merged the ERB stuff. Again, the symlink belongs into yell-rails, as you want to comply to Rails:

"By setting :symlink = true by default, Yell keeps a consistent API to the legacy Rails logger: log/development.log, etc." ;-)

Also, tail -f development.log only works until the :datefile adapter rolls over. After that, your tail has a file handle that does not exist anymore, since the symlink has been recreated onto another destination.

# in irb
logger = Yell.new :datefile, :symlink => true, :date_pattern => "%H-%M-%S"
loop { logger.info :info; sleep 0.5 }

# in your console
tail -f development.log

You will notice that the tail does not work after rollover on every second.

Contributor

nengxu commented Oct 24, 2012

You are a fun guy to argue with ;-). My statement you quoted is for
Yell's usage within Rails, together with yell-rails. However, even in
Rails, I can still use Yell without the yell-rails gem, for example, for
background jobs logging. So :symlink doesn't belong to yell-rails.

The tail example, is just an example. A developer should be able to
figure out the rollover. Take your trivial example, if :symlink is
true, he can simly Ctrl-C, and press the up arrow, enter, then tail the
new file. If :symlink is false, he has to do more typing. Do you like
more typing? Do you want to remember which second you are in now? Every
second, superman. Thanks for this very good example.

There are easily more real life examples. Just think, everytime you
refer to the log file, you have to figure out the exact strftime
formatted name. Will :symlink default to true cause you any problem? It
is just an option, man. Could you please turn the coin? ;-)

On Wed, 24 Oct 2012 02:01:44 -0700
Rudolf Schmidt notifications@github.com wrote:

OK, so I've merged the ERB stuff. Again, the symlink belongs into
yell-rails, as you want to comply to Rails:

"By setting :symlink = true by default, Yell keeps a consistent API
to the legacy Rails logger: log/development.log, etc." ;-)

Also, tail -f development.log only works until the :datefile
adapter rolls over. After that, your tail has a file handle that does
not exist anymore, since the symlink has been recreated onto another
destination.

# in irb
logger = Yell.new :datefile, :symlink => true, :date_pattern =>
"%H-%M-%S" loop { logger.info :info; sleep 0.5 }

# in your console
tail -f development.log

You will notice that the tail does not work after rollover on every
second.


Reply to this email directly or view it on GitHub:
#9 (comment)

Normally when I have config files I do this.

    def yaml_settings
      return @@yaml_settings if @@yaml_settings
      @@yaml_settings = {}.with_indifferent_access

      ['default', Rails.env, Socket.gethostname, "#{Socket.gethostname}.#{Rails.env}"].each do |s|
        filename = Rails.root.join("config", "settings.#{s}.yml")
        next unless File.exists(filename)

        begin
          settings = YAML.load_file(file)
          # Merge settings into current settings hash (recursively)
          @@yaml_settings.deep_merge!(settings)
        rescue Exception => ex
          puts "Settings couldn't be loaded from #{file}: #{ex.message}"
        end
      end
      @@yaml_settings
    end
  end

This allows me to set host specific settings which is sometimes important when you are running a cluster. Also the developers can override settings based on which machine they are working on. The environments for the build server, dev servers, staging server, web cluster etc might be different and this takes care of it.

BTW I agree with @nengxu for a long time I was only using yell for the rake tasks and using the standard logger. I was using an older version of yell and used the option :symlink_original_filename => true that worked even without yell rails

Owner

rudionrails commented Nov 28, 2012

Well, I'd rather not put the above code into the yell core, since every programmer has an own style of doing that. yell-rails is merely a convenience wrapper around yell to automatically load the yell.yml as the Rails.logger. If you do have special needs for your environment, I'd recommend not using the yell-rails gem and simply set an initializer like so:

# config/initializers/yell.rb

yell_config = {}.with_indifferent_access

['default', Rails.env, Socket.gethostname, "#{Socket.gethostname}.#{Rails.env}"].each do |s|
  filename = Rails.root.join("config", "settings.#{s}.yml")
  next unless File.exists(filename)

  begin
    settings = YAML.load_file(file)
    # Merge settings into current settings hash (recursively)
    yell_config.deep_merge!(settings)
  rescue Exception => ex
    puts "Settings couldn't be loaded from #{file}: #{ex.message}"
  end
end

Rails.logger = Yell.new( yell_config[Rails.env] )

What I tend to do from time to time is something like this:

$ ls -l config

config/yell.yml
config/yell.localhost.yml
# This is a simplified example
file = Dir[ "config/yell.localhost.yml", "config/yell.yml" ].first

Yell.load! file

As you can see, everyone has an own flavour of doing things. So, I'd rather let the individual decide how to load settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment