I posted here a while ago for input on a logging package I was working on. It has now matured to a point where I feel confident to advertise it as stable to the public. It's designed to be relatively easy and straight forward to use, but in its core it is aimed more at developers than casual users.
Cornerstones:
Hierarchical loggers like in log4j and python logging. This is useful if you want to be able to configure logging on a per-package basis.
An arbitrary number of appenders for each logger. A single logger can write to the console, a logfile, a database, etc... .
Allow for custom fields in log events. As opposed to many other logging packages for R a log event is not just a message with a timestamp, but can contain arbitrary data fields. This is very helpful if you want to produce logs that are machine readable and easy to analyze.
Support for configuring Loggers with yaml config files (experimental)
Consistent API based on R6 classes which makes it easy for you to extend
lgr is available from CRAN and github. If you are interested, please take a look at the vignette
There is also a pretty recent that aimed to rethink the existing logging packages.
I am curious if you have you already compared features and/or discussed with @daroczig about your respective views on all this ?
It is nice to have some new on for logging are there were so many already, not using new helpers (like glue) but I find it hard to choose on which to use (and learn as they are new). I believe logging API is a matter of preference and it is why there is so many different choices...
With an R6 API, there is also another in dev logging framework : logrrr
@daroczig and I started working on our logging packages around roughly the same time without being aware of each other and we had some discussion on this in the past.
It's true that there is an obscene amount of logging packages for R now. Most of them are ports of the basic idea behind log4j/python logging. I might be biased here but I feel lgr is the most complete python-logging clone yet.
This happened more or less by accident. Usually I would add a feature, revise it a few times, and then realize the final solution is the same path python logging choose. So at some point I decided just to go for it and use the python logging doc as design inspiration. The plus of this is that there is a lot of documentation/howtos/best practice guides for python logging that apply 1:1 to lgr (if you wrap your head around the differing terminology)
lgr has a pretty intuitive support for arbitrary data fields in log events, so it's a good choice if you want to produce machine readable logs (which you is something that you should want). The R6 approach makes pretty complex Appenders possible and provides a pretty clear api for extending lgr (creating your own appenders and loggers).
If you don't need any of the more advanced features it doesn't really matter which logging package you choose. If you have already used python logging / log4j and are missing some of its features in other logging packages, chances are good lgr will have them (if not, file an issue).
I am not used to python logging. Currently I use futile.logger or debugme.
I agree that Machine readable log is something important in some application.
I used futile.logger before, but started developing lgr because I needed the ability to have multiple appenders for a single logger. if futile.logger already does everything you need the main advantage of lgr would be colour output in the console and less overhead, though the same is true for logger.
lgr also has helpers for temporarily disabling /enabling logging which is useful if you write unit tests for functions with logging.
FTR logger is also on CRAN for a while -- and as always, looking forward to any feedback / suggestions etc on the package and docs (on which latter I've spent more time than the actual R code)
that aimed to rethink the existing logging packages.
