feat(log)!: support multiple loggers
This pull request dissociates tempest/debug from tempest/log, among other improvements.
- Logger now support tagged configurations
- All log files default to being in
.tempest/logsinstead of./log - The debug package has its own config for defining the debug log file
- Debug tailing is now more readable
- Channel properties are now properly commented
- Channels support minimum log levels
- The single
tailcommand and thetail:projectone have been removed, there's justtail:debugandtail:logsnow
~~This is still a draft because I feel like there could be better APIs for the config, but not sure what exactly. The issue right now is that if you don't know about the existing channel classes, you have to look up the docs, because the channels property is an array.~~
~~Maybe I'm overthinking and it's fine as-is? Currently, it looks like that:~~
return new LogConfig(
channels: [
new DailyLogChannel(
path: internal_storage_path('logs', 'tempest.log'),
maxFiles: env('LOG_MAX_FILES', default: 31),
prefix:env('APPLICATION_NAME', default: 'tempest'),
),
],
);
EDIT: ended up using the same pattern as everywhere in Tempest—dedicated config files, with one config allowing for multiple channels.
return new DailyLogConfig(
path: internal_storage_path('logs', 'tempest.log'),
prefix: env('APPLICATION_NAME', default: 'tempest'),
maxFiles: env('LOG_MAX_FILES', default: 31),
);
Due to this change, this PR unfortunately becomes breaking.
As a reminder, to log differently in different environment, we can have logging.<env>.config.php files.
TODO:
- [x] Update documentation
Looks clean!
How will we handle the breaking change? Is there a way we can keep the old way for now but deprecate it? Just so that we can have this in 2.x already and don't have to wait until 3.x
There would be naming conflicts with the new LogConfig interface unfortunately. That would be a log of glue code too...
To be honest, the breaking change is minor: if users have a custom logging config, it will be ignored in favor of the default one
EDIT: actually, it won't be ignored, it will crash because they'd be instantiating an interface
I'm fine merging it in; but we should provide a rector for it then. Are you up for that? Otherwise I'll take care of it
I updated the PR to bring some other improvements, notably tagged configurations, in order to have the ability to have multiple loggers for different purposes, which is actually quite important!
I also added docs to the PR, so it's ready to be merged.
@brendt, I tried making a Rector rule for the breaking change, but couldn't manage, so if you still want to, you can do it 😓
This pull request is stale because it has been open for 30 days with no activity.
@brendt can we merge?
I'm on the fence about it if we don't have a rector for it. Gonna ask around on Discord for some real life examples.
./tempest tail:debug causes my CPU temperature to rise by 15 degrees :smile: Maybe it's busy waiting? I'm using linux
btw. related XKCD https://xkcd.com/1172/
causes my CPU temperature to rise by 15 degrees
Do you mean with this branch?
causes my CPU temperature to rise by 15 degrees
Do you mean with this branch?
Yes, but now I checked and it's the same on main, so not a regression, sorry^^
Gonna ask around on Discord for some real life examples
I believe many people indeed are using custom logging config. I would only be comfortable merging this in 2.x if we have an automated upgrade for it. I'm not sure that'll be trivial to do though 😬
I briefly looked into it, and I'm not sure we can do what we need to do with Rector to automate this upgrade. That being said, maybe my Rector knowledge is lacking.
Maybe we should simply start preparing for 3.0 and include this one in there?
Personally I would say the Tempest community is small enough for us to be able to make that breaking change on a minor version 😬
That being said given your question on the Discord server I would say that few are actually customizing it
If you really don't want the breaking change though, we can create a 3.x and merge this
I've given it some more thought and I think I'd like it to be targeted toward 3.x.
I'm ok tagging 3.x soon though. Let's aim for the beginning of January? That way I can finish my FrankenPHP PR, and then we'll merge 8.5 support in 3.x as well
@innocenzi feel free to merge in 3.x when you're ready