deps.rs
deps.rs copied to clipboard
Check Cargo.lock for Bin Crates
I've got a two year old repo that shows as up to date:
Crate | Required | Latest | Status |
---|---|---|---|
gtk | ^0 | 0.3.0 | up to date |
hyper | ^0 | 0.11.19 | up to date |
This is because the deps are specified like:
[dependencies]
gtk = "^0"
hyper = "^0"
But the lockfile shows the deps are actually locked to much older versions:
dependencies = [
"gtk 0.0.7 (registry+https://github.com/rust-lang/crates.io-index)",
"hyper 0.9.7 (registry+https://github.com/rust-lang/crates.io-index)",
]
Thanks for raising this!
Lockfile support is something I‘m working on. I‘ll make sure to cover this use-case as well!
I like to keep lock files in git for my lib crates as well, and have only some CI runs remove the Cargo.lock for testing the very latest dependency patch releases. Thus if deps.rs showed I was falling behind in either Cargo.toml or Cargo.lock, that would be helpful to me and my users alike. I would think most projects that have a Cargo.lock checked in (be they bin or lib) would want this. Bonus points if the badge or details page made some distinction between the two (toml dep ranges vs lock file versions) obvious.
This would indeed be nice to support both for binary program crates as well as for git repositories!
We had a specific problem in https://github.com/EmbarkStudios/rust-gpu/pull/132 where our tar
dependency, and as such the entire repo in the badge, got flagged as "insecure", even though we through Cargo.lock was using a newer secure patch version of it.
That was easy to workaround to also specify that patch version in Cargo.toml, but if deps.rs would have supported Cargo.lock it wouldn't have been flagged incorrectly to start with.
No big deal, but thought I should mention that specific use case here also