glog package -log_dir undocumented & flag usage

[Geert-Johan Riemer]

Hi,

I was searching for a way to set the log output directory and found how to do it when reading the source code.
The log_dir flag seems to be undocumented.
https://github.com/golang/glog/blob/master/glog_file.go#L41

On a related note:
I think it would be nice to expose the settings directly in the package, instead of forcing the usage of the `flag` package.

/GeertJohan

[Geert-Johan Riemer]

Rob Pike fixed this by adding documentation
https://github.com/golang/glog/commit/c6f9652c7179652e2fd8ed7002330db089f4c9db

Thanks.

[David Chung]

There's one more caveat... and perhaps another argument for exposing the settings directly rather than via flags:

The log_dir flag will have no effect, if glog is called before the flag.Parse(), because log directories are created via the onceDirs.Do(createLogDirs).  This can happen if a program depends on code in some library package and that library package calls glog to log in its init() block.   During init(), the logDir flag is not parsed (with "" as default), and logs are sent to a os.TempDir() which the user doesn't know.  So it will just look like it's not logging.    Logging calls after flag.Parse() will not create the log dir as specified because of the sync.Once.  

Thanks.

[Rob Pike]

Don't log in init. You should avoid I/O during initialization in any case.

As the docs make clear, glog is just an export of a Google-internal
package. It's there because many people have asked for "leveled"
logging and the package shows one efficient way to provide it; the
public packages I've seen provide no way to avoid evaluating the
arguments to the logging call. Plus it's got a couple of nice
features, like -vmodule. And it's thoroughly tested, thread-safe, and
robust, and does things like file rollover at midnight. It's
production-ready.

But the package is designed for Google, and in particular to match in
minute detail the external behavior (files, flags, etc.) of an extant
C++ logging package. It's unlikely to be a perfect fit for just about
anyone else, although it's quite usable.

The package is what it is, and it will evolve only as the internal
Google package evolves.

If you want something different, it's open source and you are free to
take the source or its ideas and provide an alternative. As I've said
before, I hope someone will.

-rob

[David Chung]

It's quite a lovely package actually.  As a Xoogler who used to work with the c++ versions of the gflags and glog libraries, these packages really make a newcomer to go feel at home.

As it turns out, we have code in the init of one package calling some public function in another package.  That function logs a warning for some error conditions.  Because it was called in the init in another package (not knowing that the function tries to log or do I/O) and the error hit and triggered a logging call, so the logs were written only in the os.TempDir and not in the specified log directory.   It took a little bit of digging to figure out, but overall it was a good learning experience on the best practice dealing with package initializations via init() and responsibilities in error handling.