-
Notifications
You must be signed in to change notification settings - Fork 721
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remove log
dependency
#1666
remove log
dependency
#1666
Conversation
Currently, Mio depends on `log`. In rust-lang/log#552, the `log` maintainers aim to increase `log`'s MSRV to 1.60. This MSRV increase would impact Mio, which in turn, would impact Tokio. As of 1.25, Tokio supports Rust 1.49 with the intent of supporting it until March 2024. Mio mostly uses the `log` dependency for debugging/tracing. Removing the `log` dependency has minimal impact and is the easiest way to resolve the MSRV issue. Additionally, this is another step towards minimizing Tokio's dependencies.
I have no idea why FreeBSD CI is failing. |
I'm very much against this. I use the logs to debug problems. |
Are you OK with making it a dev dependency? |
Though, I don't think there is a great way to check if dev dependencies are available conditionally. @Thomasdezeeuw What do you propose? Tokio cannot depend either directly or transitively on any crates that break its MSRV policy. |
No as users need to enable it when the have a problem, if we have it in the tests only it's pretty useless. |
That's nearly every crate. A MSRV policy just doesn't work, we need something better like e.g. 6 months support of released rust versions, but that's a large story. |
Another option is to gate it by a |
Perhaps, but for a library like Tokio, I consider the ability to have toolchain stability valuable. We have an LTS/MSRV policy today that we need to try to maintain. |
It might make sense for That way we could minimize the amount of code |
Isn't that the point of the |
@Thomasdezeeuw You're totally right, and we try hard to make it as broadly compatible and opinion-free as possible. But it's still an outside artifact. If you need strict control over some property of your system that a dependency isn't satisfying then you're pretty much stuck taking responsibility for implementing it yourself. |
I'm not sure if it will work but can Tokio (v1.25) add a direct dependency on |
I don’t believe that would work. Given a dependency tree, finding the idea set of versions that satisfies it is an NP complete problem. To run dependency resolution in a reasonable time, cargo will opt to duplicate dependencies. In this case, depending on how it traverses the dep tree, it could end up with two versions of log. Besides still having the MSRV issue, multiple versions of log could cause other problems for users because log uses static variables to store the specific logger. |
I might be misremembering, but I don't think |
On the subject of MSRV, I think your interpretation of the MSRV policy for Removing |
Tokio maintains LTS branches to support users that prefer toolchain stability (i.e., they would instead update occasionally vs. constantly). In case of a security fix or a major bug fix, we will backport these fixes to the LTS branches. This way, more conservative users can get the fixes without the risk of disruption from regressions introduced by more significant changes. In the event of a security or significant bug in a transitive dependency, we also need Tokio users to be able to get those fixes. For example, if a security issue is discovered and fixed in Additionally, I would like Tokio's LTS branch CI to be green. When we backport fixes to LTS branches, I would like the process to be as smooth as possible. We don't currently check in
I agree that forcing the entire ecosystem to a pinned version of |
A potential alternative solution would be to replace the Mio's tests etc can probably be converted to use |
Having |
I don't really want to switch to the tracing crate as the log crate is sufficient for our purposes, furthermore that would be a breaking change as the logs won't appear if you don't have a tracing implementation/logger set up (assuming they don't enable the
I don't think it's fair to the ecosystem to hold back the log crate because some users require support for a very old rust version, so I'd say a is unreasonable. That leaves option b... but I don't want to remove it for non-Tokio TLS users as the logs allow you to quickly debug issues. Maybe Tokio TLS version can use mio-tls version that uses an older MSRV that removes the |
Do you mean maintaining a fork of When it comes to debugging problems, could we rely on tools like |
@Thomasdezeeuw how hard would it be to add a feature to use tracing instead of log? |
tracing has a feature "log" which brings in log as a dependency and emit log events instead. So maybe mio could actually switch to tracing, add a new feature "log" that is enabled by default for backwards compatibility. Crates like tokio can disable default features so that it is not affected by the msrv bump. |
@carllerche Yes, just another branch in this repo that Tokio TLS versions can depend on.
Yes, @Keruspe @NobodyXu I have zero interest in switch to |
If we go that route, I would most likely lean towards pulling Mio into Tokio itself instead of adding a separate crate. |
Well it won't be a separate it's just Mio, slightly modified for old Tokio versions. But if you prefer to maintain Mio inside of Tokio itself, that's always an option. |
Has the possibility of having it be an ordinary optional dependency been discussed anywhere? |
Is the concern there just that applications that are already deployed would need to be rebuilt in order to get diagnostics when they misbehave? A feature gate seems like the path-of-least-surprise to me though. |
Not yet.
We could make the |
@carllerche what do you think of @Darksonn's idea?
|
Closed in favor of #1673 |
Currently, Mio depends on
log
. In rust-lang/log#552, thelog
maintainers aim to increaselog
's MSRV to 1.60. This MSRV increase would impact Mio, which in turn, would impact Tokio. As of 1.25, Tokio supports Rust 1.49 with the intent of supporting it until March 2024.Mio mostly uses the
log
dependency for debugging/tracing. Removing thelog
dependency has minimal impact and is the easiest way to resolve the MSRV issue. Additionally, this is another step towards minimizing Tokio's dependencies.