Description
Current and expected behavior
kube-runtime
pulls in two distinct versions of pin-project
& pin-project-lite
:
:; cargo tree -d -i kube-runtime
pin-project v0.4.28
└── snafu v0.6.10
└── kube-runtime v0.63.2
pin-project v1.0.8
├── kube-client v0.63.2
│ └── kube-runtime v0.63.2
├── kube-runtime v0.63.2
├── tower v0.4.10
│ └── kube-client v0.63.2 (*)
└── tower-http v0.1.2
└── kube-client v0.63.2 (*)
pin-project-internal v0.4.28 (proc-macro)
└── pin-project v0.4.28 (*)
pin-project-internal v1.0.8 (proc-macro)
└── pin-project v1.0.8 (*)
When using tools like cargo-deny
to audit dependencies, this requires an exemption like:
[bans]
multiple-versions = "deny"
# Wildcard dependencies are used for all workspace-local crates.
wildcards = "allow"
highlight = "all"
deny = []
skip-tree = []
skip = [
# kube-runtime pulls in snafu v0.6, which pulls in an older version of pin-project
{ name = "pin-project", version = "0.4.28" },
{ name = "pin-project-internal", version = "0.4.28" },
]
I imagine this bloats compile times for packages that use kube-runtime
, though I don't have hard numbers to back up this assumption.
Possible solution
I'd love it if we could drop the snafu
dependency entirely, just to avoid the dependency. I know it offers some conveniences, but these seem surmountable, especially if we use thiserror
for error definitions. thiserror
is already pulled in by kube-client
and kube-core
.
Otherwise, it looks like there's a snafu
v0.7 release in the works that hopefully resolves this?
Additionally, it may be valuable to use something like cargo-deny-action
to audit duplicate/mismatched dependencies, license compliance, etc.
Additional context
No response
Environment
n/a
Configuration and features
:; cargo tree -p kube --depth=1
kube v0.63.2
├── k8s-openapi v0.13.1
├── kube-client v0.63.2
├── kube-core v0.63.2
├── kube-derive v0.63.2 (proc-macro)
└── kube-runtime v0.63.2
Affected crates
kube-runtime
Would you like to work on fixing this bug?
maybe