fogfog-awsfog-google

Best practices to use Fog::Logger


What are the best practices to use Fog::Logger. Fog provides 3 types of logging:

  1. debug
  2. deprecation
  3. warning

    module Fog
      class Logger
        @channels = {
          :deprecation  => ::STDERR,
          :warning      => ::STDERR
        }
    
        @channels[:debug] = ::STDERR if ENV["DEBUG"]
    
        def self.[](channel)
          @channels[channel]
        end
    
        def self.[]=(channel, value)
          @channels[channel] = value
        end
    
        def self.debug(message)
          write(:debug, "[light_black][fog][DEBUG] #{message}[/]\n")
        end
    
        def self.deprecation(message)
          write(:deprecation, "[yellow][fog][DEPRECATION] #{message}[/]\n")
        end
    
        def self.warning(message)
          write(:warning, "[yellow][fog][WARNING] #{message}[/]\n")
        end
    
        def self.write(key, value)
          channel = @channels[key]
          if channel
            message = if channel.tty?
                        value.gsub(Fog::Formatador::PARSE_REGEX) { "\e[#{Fog::Formatador::STYLES[$1.to_sym]}m" }.gsub(Fog::Formatador::INDENT_REGEX, "")
                      else
                        value.gsub(Fog::Formatador::PARSE_REGEX, "").gsub(Fog::Formatador::INDENT_REGEX, "")
                      end
            channel.write(message)
          end
          nil
        end
      end
    end
    

    If we use debug logging then it is only visible when debug mode is on. What is the best way to use it, please give some examples if possible.


Solution

  • The logger is intended for messages from fog to end users, rather than for direct use from end-users. I would suggest the levels would be used something like this:

    1. debug - Not really used much, more for usage during development than something I would expect to be used for messaging to end-users.
    2. deprecation - Any time we have changed a behavior, but left a backwards-compatible adapter we try also to have a deprecation warning explaining and hopefully driving users to update.
    3. warning - This makes sense for anything related to usage that the user should be made aware of in addition to what is happening (ie if something changed on the provider side or the provider returns a warning, but it isn't broken enough to actually raise an error).

    Hope that helps, but certainly happy to discuss further as needed.