Give more control over file names in tracing-appender

[SadiinsoSnowfall]

Feature Request

Crates

This concerns the tracing-appender crate.

Motivation

Add more control over the resulting file name(s) when using tracing-appender. In some case, it can be better to have all log files ends with the same extension (.log for example) which is currently not possible achieve with tracig-appender as the crate create file names with a date appended at the end and the user can only control the file prefix (example: logs_directory/log_file_name_prefix.yyyy-MM-dd-HH-mm).

Proposal

a) Add a way to set a suffix for file names, similar to how the prefix work.
or
b) Add a way to set a custom formatter for file names, which would take parameters such as the date to include and return a file name to use for example :

let appender = tracing_appender::rolling::daily("/var/log/", |date| {
    format!("app_name.{:?}.log", date)
});

(this is only an example, an implementation of this feature could use a new "constructor" function to avoid creating a breaking change)

[hawkw]

I think the second approach you proposed where a rolling appender can optionally be constructed with a closure, seems like the most flexible approach, so I'd prefer to go with that.

You're right that, to avoid breaking changes, we may want to either add new constructors for the file appenders that take a closure. We could add new hourly_custom, daily_custom, etc constructors.

Another approach could be to add a new trait for generating a file name, which is implemented by T: AsRef<Path> (as a prefix) or by a closure (or newtype wrapping a closure). This way, we could still accept AsRef<Path> in that argument, but could also accept a function. However, I'm not immediately sure if we could do this without running into orphan rules issues, since we would need a blanket impl for T: AsRef<Path> to avoid the breaking change...

Is this something you're interested in helping to implement?

[SadiinsoSnowfall]

I think making the shortcut functions (minutly, hourly, daily, etc) directly might lead to confusion from the users: the parameter name would not reflect the fact that it can be a simple file prefix and the user would have to read the doc to understand the trait. I think it would be better to use new function names such as hourly_custom. The current hourly function is just a shortcut for RollingFileAppender::new anyway.

If we decide to use a trait instead of a String/&str/Path inside the internal functions, then what should we pass to the trait functions when formatting ? If we pass the raw DateTime to the trait impls, it will be up to the user to format correctly the date, which is not really a problem; but we would also have to move the date formatting logic from the Rotation impl to the trait impl for AsRef<Path> or &str, which would also required passing the rotation kind to the impl, in order to know how to format the date.

[SadiinsoSnowfall]

I have created a branch on my github account which contains a first draft implementation of this feature. There is currently two problems with this implementation: first the RollingFileAppender is now generic because InnerAppender is generic over the custom formatter trait (implemented by T: AsRef<Path> and a newtype used to wrap the lambda). This might cause a breaking change because the generic parameter must be set.

Another problem is that the newtype used to wrap the lambda must be public, this is required because RollingFileAppender can be generic over this type (I don't think we can avoid using a newtype because implementing the custom formatting trait directly on the function type causes an implementation collision with T: AsRef<Path>).

[lilyball]

I would also like to have the ability to have the current log always just be prefix.log and have it be renamed to include the date when rolled over. I don't know if this should use the date at the rollover point, or the log's start date (via the file creation date), I don't know which is more common in other log rollovers, I mostly just want the "current" log to always have the same name.

Also on a related note, existing rollover implementations (including macOS's handling of /var/log/system.log) just use incrementing numbers, such that all of the rollover logs are renamed on each rollover. This might be a useful naming scheme to support as well, it just means adding the ability to rename existing rollover logs when rolling over. This approach also makes it trivial to bound the number of logs as you can simply overwrite the oldest log with the rename if you've hit the limit.

[HaeSe0ng]

Would this feature be implemented soon?

[bryangarza]

@HaeSe0ng -- I don't think anyone is actively working on this at the moment, but we'd be glad to accept PRs.