tokio-codec does not contain length_delimited

[twittner]

Version

tokio-codec 0.1.1
tokio-io 0.1.9

Platform

Linux 4.18.10-arch1-1-ARCH #1 SMP PREEMPT x86_64

Subcrates

tokioc-codec
tokio-io

Description

PR #568 deprecated tokio_io::codec::length_delimited. The deprecation warnings, e.g.

warning: use of deprecated item 'tokio_io::codec::length_delimited': Moved to tokio-codec

claim the module has been moved to tokio-codec, however this is not the case. tokio now contains a codec::length_delimited module, but the tokio-codec crate does not. Users who do not use the tokio crate have therefore no upgrade path.

[hawkw]

I think the deprecation warnings need to be updated to say "tokio::codec" rather than "tokio-codec".

As for

Users who do not use the tokio crate have therefore no upgrade path.

@carllerche and @kpp suggested that length_delimited move to the tokio crate in issue #500; perhaps they have some input regarding this concern?

[carllerche]

The deprecation in tokio_io needs to be updated to reference tokio::codec instead of tokio_codec.

[Kixunil]

While using tokio::codec instead of tokio_codec might work, I don't like having to depend on tokio crate from library crate. I have a library crate that uses length_delimited but I don't want to force users into depending on lot of other things in all tokio-related crates that they don't use.

Please consider adding length_delimited to tokio_codec itself.

[kpp]

I don't like having to depend on tokio crate from library crate.

That's a good reason.

[carllerche]

@Kixunil #808 should resolve this issue. You will be able to depend on tokio but only with the components you need (like length_delimited).

[Kixunil]

Thanks, that should be good! I wonder though, why exactly this approach was taken instead of separate crates. Is it documented somewhere?

[carllerche]

@Kixunil took me almost 90 minutes to publish the last round of crates...

[carllerche]

I'm going to close this as Tokio w/ feature flags has been pushed. You can depend on the tokio crate while only pulling in components you need.

[Kixunil]

That's reasonable, thanks a lot for everything!

[twittner]

You can depend on the tokio crate while only pulling in components you need.

@carllerche: I think the current state of feature resolution in cargo prevents this from working properly in practice, e.g. when compiling for different targets. See for example: rust-lang/cargo#1796, rust-lang/cargo#4866.

[carllerche]

@twittner could you explain the exact problem scenario?

[twittner]

A Cargo.toml such as

[package]
name    = "foo"
version = "0.1.0"

[target.'cfg(target_arch = "wasm32")'.dependencies]
tokio = { version = "0.1.14", default-features = false, features = ["io"] }

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
tokio = { version = "0.1.14", default-features = false, features = ["io", "tcp"] }

which selects different tokio features depending on the target architecture will ― for all target architectures ― build with the union of all feature sets. The example will therefore fail to compile on wasm32.

[carllerche]

A workaround could be for Tokio to never pull in features that don’t work on the platform... so on wa even if you ask for tcp you wouldn’t get it.

Or cargo could fix the issue.

[kpp]

A workaround could be for Tokio to never pull in features that don’t work on the platform

Actually I don't want tokio-uds or tokio-fs while I include tokio in my project.

[carllerche]

@kpp this is possible today by using feature flags.

[kpp]

Ah thanks