Closed ds-cbo closed 10 months ago
rustc-serialize appears to be an optional dependency of an optional dependency. It's not clear to me why cargo would be complaining about it unless you have actually activated it?
eui48
is a non-optional dev-dependency of tokio-postgres
, so is already included with a simple cargo test
. rustc-serialize
is an optional but enabled-by-default feature of eui48
versions 1.0 and up, but required dependency on the 0.4 branches.
We might also be able to get away with this issue partially by setting default-features = false
on our eui48-1
dependencies, but that won't fix eui48-04
being a hard dev-dependency
. Perhaps make that one disabled by default? Then at least cargo test
will keep working in the future.
You can't define optional dev-dependencies unfortunately. https://github.com/rust-lang/cargo/issues/1596
That's a bummer. Would you agree to disable default features (that's only backwards compatability support for rustc-serialize
) for eui48-1
now and eventually drop support for eui48-04
when https://github.com/rust-lang/rust/issues/105572 is turned into a hard compilation error?
Yeah that seems like the best route forward.
Actually, I think we'd be better off just removing the 0.4 tests rather than dropping support entirely for now. Once the MSRV of tokio-postgres is on a version that doesn't build rustc-serialize we can remove it entirely.
I already had that approach in mind, PR is incoming
While compiling tokio-postgres with
cargo 1.75.0-nightly (794d0a825 2023-10-03)
, I got the following error:However, it is no longer possible to file a report with
rustc-serialize
since they got archived in August 2021.The dependency within
rust-postgres
which pulls inrustc-serialize
iseui48
. They have been made aware of this issue in January 2022, but there is no response from the author and seemingly only maintainer of the repo @abaumhauer who hasn't committed to the repo since August 2020.To make sure that
rust-postgres
will still compile with future versions of the Rust compiler, I would suggest replacing theeui48
dependency. Others have seemed to move to one of:Out of these, I would suggest using the first one since it has the least amount of dependencies and is probably least likely to break as a result.