CRAN/release targets
We should settle on features that we focus on for a first release; something like
- logging of events raised with
message,warning,stop, without need for the user to change code to achieve this (no need for calling handlers, tryCatch etc). - main log events; DEBUG, INFO, WARN, ERROR, CRITICAL.
- (multiple) console and file outputs.
- default formatters (file, json, ?)
- switch to ignore/include suppressed warnings & messages
- vignette?
- string interpolation (maybe include explicitely, until a part of CRAN stringr)
Other?
cc @richfitz @Ironholds
Sounds good. JSON output requires a json writing dependency (I'm using jsonlite at work). Happy to merge that in if you'd like.
+1 on vignette.
I made a small package loggr.redis with Redis support; I do not suggest porting this in yet (the Redis stuff is not yet on CRAN) but just figured you should know. So far it's working great :)
Awesome! Also with the newest push I made, where I changed the way trace is hooked up?
Would it be an idea to have jsonlite as a Suggests? So that trying to use the formatter will fail if not installed, and so a required dependency is not needed. Maybe not such a big issue.
Also, should we include string interpolation (internal use only) and then import if and when stringr includes it in a CRAN release?
jsonlite as a suggests would work fine.
This was with the version before your change but will check that everything works OK on Tuesday. I don't see that it would have stopped working though.
String interpolation - I don't have a strong feeling about that, though I am excited to give it a play in general.
Sounds good.
I made a PR for stringr based on another issue/feature request; one was merged, but the have an update to it that is not merged. But I think we should just include the functionality internally until it is final in stringr. Makes logging that depends on values easier. I can try putting it in here soon.
RE string interpolation: Just pushed this. Either provide a regular string (as usual) to the log functions, or use a formula, in which case interpolation will occur:
library(loggr)
user <- "smbache"
dollars <- 6.656
log_info(~"The user '${user}' has an account with €$[.2f]{dollars}.")
# => 2015-06-14 15:00:00.311 - INFO - The user 'smbache' has an account with €6.66.
Strooongly against jsonlite as a "Suggests". If functionality doesn't work without a package, that package is by definition a dependency. Putting it as "suggests" creates a situation similar to the highly frustrating nonsense around tm, which depends on SnowballC but, instead of requiring it, simply errors out and tells you the function you're calling is in turn calling a function that doesn't exist.
Fair enough; I guess jsonlite is solid and we could import instead. The reasoning for not suggesting that was that I think few will actually use the json formatter (relatively) and the additional imposed install is not useful all around. But I guess jsonlite is quite common already.
Other inputs?
I think we're relatively close to something useful now ; we still need the json formatter, and a vignette. And perhaps some minor adjustments, say the dot arguments and subscriptions..
This is a really great package, been using it for a few projects now. Happy to help with documentation, etc. if CRAN is still a target?