search

grafana / k6foundry

k6 dynamic build library
GNU Affero General Public License v3.0
0 stars 0 forks source link

Change log library to slog #17

Open szkiba opened 2 weeks ago

szkiba commented 2 weeks ago

Logrus does not offer some functionality such as context-based logging that may be useful in the build service and this features are not expected to be included as the library is in maintenance mode.

I would recommend using standard log/slog instead of logrus. If we wan't a logrus like output in a specific CLI then just use logrus slog adapter in app initialization code (main package).

https://github.com/grafana/k6foundry/blob/a668c34830f1d1dc3e083bf83cccf06e24e1f574/native.go#L12

pablochacin commented 1 week ago

k6 uses logrus. Also, there's nothing wrong with using it a it is clearly stated in logrus' repository:

Logrus is in maintenance-mode. We will not be introducing new features. It's simply too hard to do in a way that won't break many people's projects, which is the last thing you want from your Logging library (again...).

This does not mean Logrus is dead. Logrus will continue to be maintained for security, (backwards compatible) bug fixes, and performance (where we are limited by the interface).

szkiba commented 1 week ago

k6 does use logrus, but for historical reasons. The situation is quite different in the case of a development that is just starting.

szkiba commented 1 week ago

Here is an example (from k6x) of how to prepare slog so that the output is produced with logrus.

https://github.com/grafana/k6x/blob/master/main.go#L25

szkiba commented 1 week ago

One of the most important uses of k6foundry will be in the build service. Logging is an important topic in a service. It may be necessary to set the log level per request, which can be implemented with context-aware logging. In the case of logrus, it is not possible to set the per request log level. Since it is in maintenance mode, no new feature development is expected.

Therefore, it should be considered in the long term to choose a log library that is being developed actively. Since the log/slog package appeared in go 1.21, its use should be considered.

pablochacin commented 1 week ago

Then the problem is not about logrun being in maintenance mode, but that we may want functionality that is not available.

I agree. I change the title of this issue (or open another issue) because the title of this issue are misleading.

szkiba commented 1 week ago

Then the problem is not about logrun being in maintenance mode, but that we may want functionality that is not available.

I think both are problems, but one is more strategic (maintenance mode)

I change the title of this issue (or open another issue) because the title of this issue are misleading.

OK, that would be better.