-
Notifications
You must be signed in to change notification settings - Fork 1k
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
feat(channel): Make channel feature additive #1574
feat(channel): Make channel feature additive #1574
Conversation
633ffb2
to
32dbd14
Compare
a8d667a
to
1fe8cb0
Compare
1fe8cb0
to
4d0d3ea
Compare
4d0d3ea
to
2f5ab49
Compare
44071c7
to
bfdac3b
Compare
bfdac3b
to
4c3efe5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks interesting, but in its current form I find it hard to review. Would you be open to splitting this into smaller commits (or separate PRs if you prefer)? In particular, moving code around would be good to have in separate commits (at least).
examples/Cargo.toml
Outdated
@@ -298,13 +298,13 @@ hyper-warp-multiplex = ["hyper-warp"] | |||
uds = ["tokio-stream/net", "dep:tower", "dep:hyper"] | |||
streaming = ["tokio-stream", "dep:h2"] | |||
mock = ["tokio-stream", "dep:tower"] | |||
tower = ["dep:hyper", "dep:tower", "dep:http"] | |||
tower = ["dep:hyper", "dep:tower", "tower?/timeout", "dep:http"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ?
isn't really needed here, right, since we already enable dep:tower
unconditionally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Saw this also in some of your other PRs, so would be good to clarify the goal here.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I tested this previously, I found that it was necessary to write it like this at the Rust version which is older than or equal to 1.70. But when I tried it again this time, it seems that it is no longer necessary.
I am not sure why the results are different even though testing is done with the same Rust version.
ref:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I find what happen. At this example project, changing both of them to tower/feature
removes all dep:tower
notation, and then it provides implicit feature. However it is hidden by the explicit tower
feature. There is no particular effect on the example, but to unify the notation, I will use ?
in the notation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand the full context of what you're saying. As far as I know, the ?
means that the feature dependency should not (by itself) activate the optional dependency itself. That doesn't apply here (we're actively enabling the optional feature), so we should not use the ?
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When using Rust 1.70 or older than the version, using dep:crate-name
and crate-name/some-feature
cannot be used at the same time because of the cargo limitation. dep:crate-name
and crate-name?/some-feature
is a workaround for the limitation. However, in this case, it seems to be overlooked by cargo due to the explicit feature which is the same name to the crate-name
(tower
in this case). Based on these premises, I prefer uniformity of notation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if we used 1.71 this limitation would be lifted? Sorry, I'm still not convinced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. When we bump MSRV to 1.71, this workaround is not needed.
Found the pull request which addressed this: rust-lang/cargo#12130.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just for examples though so I think this is fine for the moment.
json-codec = ["dep:serde", "dep:serde_json", "dep:bytes"] | ||
compression = ["tonic/gzip"] | ||
tls = ["tonic/tls"] | ||
tls-rustls = ["dep:hyper", "dep:hyper-rustls", "dep:tower", "tower-http/util", "tower-http/add-extension", "dep:rustls-pemfile", "dep:tokio-rustls"] | ||
dynamic-load-balance = ["dep:tower"] | ||
timeout = ["tokio/time", "dep:tower"] | ||
timeout = ["tokio/time", "dep:tower", "tower?/timeout"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
Also, do you have a concrete use case in mind for this? |
Sure, I will do it. |
Actually, the main purpose of this pull request is to prepare #1630, which split transport's server and channel completely. However, this alone is useful for users who want to use it only as transport server without using channel, as it reduces additional dependencies. Currently, channel feature looks an independent feature from transport, but the dependencies and implementations are not separated, so users cannot use the channel functionality without transport. |
4c3efe5
to
f455436
Compare
cec6c48
to
b48685e
Compare
b48685e
to
e409efb
Compare
"dep:tower", | ||
"dep:tower", "tower?/util", "tower?/limit", | ||
] | ||
channel = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you update the crate root documentation to clarify a bit what the distinction is between channel
and transport
? I don't think the current docs are very clear:
transport
: Enables the fully featured, batteries included client and server implementation based on hyper, tower and tokio. Enabled by default.
channel
: Enables just the full featured channel/client portion of the transport feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to reflect the state of these feature flags.
@@ -276,13 +276,13 @@ tracing = ["dep:tracing", "dep:tracing-subscriber"] | |||
uds = ["tokio-stream/net", "dep:tower", "dep:hyper", "dep:hyper-util"] | |||
streaming = ["tokio-stream", "dep:h2"] | |||
mock = ["tokio-stream", "dep:tower", "dep:hyper-util"] | |||
tower = ["dep:hyper", "dep:hyper-util", "dep:tower", "dep:http"] | |||
tower = ["dep:hyper", "dep:hyper-util", "dep:tower", "tower?/timeout", "dep:http"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the previous commit fail to compile the examples? If so, IMO we should squash this commit into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the previous commit fail to compile the examples?
Yes. Squashed these two commits.
use tokio_stream::Stream; | ||
use tower::discover::Change; | ||
|
||
type DiscoverResult<K, S, E> = Result<Change<K, S>, E>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems unrelated to the commit message?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
6849880
to
0e9cf89
Compare
Addressed the reviews, and updated the feature configs. |
0e9cf89
to
3f3acd4
Compare
3f3acd4
to
3b54bae
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, looks like we need to get #1630 updated as well.
Motivation
Allows users to use transport feature independent from channel.
Solution
Warning
This proposal includes a breaking change.
Makes channel feature additive.