Pino: Should we make "v" overridable?

[stephanebruckert]

Hello Pino team,

I would like to understand why "v" (LOG_VERSION) is compulsory and read-only.
In our case we would like to override it to represent our service version instead.
If any backward-incompatible change had to happen inside Pino, we would update to the latest Pino and bump our service version, which still gives sense to "v".

Can we make it overridable? I've requested this on Bunyan also.

Thanks, Stephane

[mcollina]

Why do you want to override it?

[stephanebruckert]

Because I want the logs to include the service version and if we think of it, the service version already infers the Pino LOG_VERSION (as the package.json contains a versioned Pino).

[davidmarkclements]

Are you sure that's a desired coupling?

Perhaps if you just add a service version to a separate property, it may avoid unforeseen difficulties

[stephanebruckert]

I can, but having "v" and "version" is a bit confusing to others. Some might wonder what is what, and also wonder what is the use of "v".
Also "v" is the ideal name which I would like to use to keep my logs short. Basically that "v" currently prevents me from outputting what I really need.
Plus, we are running services in Clojure and using a library called Timbre, which we already configured to present "v" as the service version. We wanted the Clojure logs to be consistent with the Node.js logs.

[jsumners]

My concern here is pino specific tooling. For example, the included prettifier checks for the v property to determine if the log line is appropriate to prettify. It doesn't yet check the version number, but it might become necessary to do so. Granted, this would be self inflicted breakage if you opted to change the meaning of that property, but it would mean we can't guarantee features and would always have to ask "did you change the v property?"

I don't think anyone is really asking themselves what v is for. It's clearly an indication of the log format version. However, it might be a good idea to state that explicitly in the documentation.

I present this as a possible solution:

var pino = require('pino')
var log = pino(options).child({appname: require('package.json').version})

[davidmarkclements]

this is an unfortunate naming conflict across languages and paradigms, but we basically followed bunyans lead on this - I would be reticent to break away from that - I strongly doubt bunyan will make it overridable, and unless they do I don't think we should either

[stephanebruckert]

Ok, I understand. Thanks for the quick answers!

[stephanebruckert]

FYI https://github.com/trentm/node-bunyan/issues/462 is a similar, active issue

[jsumners]

@stephanebruckert they make the same argument as I did -- it would increase the difficulty of writing tools to work with raw Pino logs. I still think using a child logger with a property specific to your application, set to the application's version, is the appropriate solution.