ref(iroh): Rename target for events

[flub]

Description

Turns out people will configure logs with RUST_LOG=iroh=debug and then the events target is completely lost. That's bad!

This changes the events to be in the main crate target, so users don't have to separately enable them.

It also changes the separators to use the ::. The driver for this is compatible with the EnvFliter syntax, allowing you do do e.g. RUST_LOG=iroh::events=debug to enable just events.

The main downside is that it is harder to enable events across different crates. But then we only use this in one crate so far, so perhaps that's not an issue yet.

Another downside is that iroh::events could quite easily become a module name, in which case the targets would conflict.

Breaking Changes

• Events are emitted on different tracing targets: iroh::events instead of events.net.
• Event names have changed to use :: as separator, previously this was ..

Notes & open questions

Perhaps there is a better name than events that is less likely to conflict with a real module? Maybe we could use an illegal character? Experimenting with iroh::-events:: as prefix does seem to work: it is accepted by the tracing and the EnvFilter is fine with it.

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.

[github-actions]

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/2977/docs/iroh/

Last updated: 2024-11-29T09:43:57Z

[github-actions]

Netsim report & logs for this PR have been generated and is available at: LOGS
This report will remain available for 3 days.

Last updated for commit: 2e7b44c

[rklaehn]

If this works for you, go for it. However, I find it a bit weird that these things look like module paths but don't actually match the modules the events are emitted in.

Given the latter, maybe having a special "module name" for the events pseudomodule would be nice to distinguish these from normal module paths.

[flub]

If this works for you, go for it. However, I find it a bit weird that these things look like module paths but don't actually match the modules the events are emitted in.

The tracing metadata also has a file field which records the file. This is however not shown by the default fmt subscriber. Also, a file name is not 1:1 mapped to a module name, so yeah. So far I have been trying to compromise between practicality and enough distinguishing semantics that you can process them automatically.

Given the latter, maybe having a special "module name" for the events pseudomodule would be nice to distinguish these from normal module paths.

[matheus23]

This makes sense to me.

Perhaps there is a better name than events that is less likely to conflict with a real module?

I suggested _events in the discord. This both avoids a conflict with a potential module (we probably will never add an _events module), and also doesn't use a special character, so wouldn't confuse some tool that only expects valid module names.