Improve display of information for outdated crates #34
Conversation
Since 0.x.y versions have slightly different semantics than 1.0 and later, add specific tests for those.
jamessan
force-pushed
the
outdated-crates
branch
from
3e01f60
to
93dbf23
Compare
src/debian.rs
Outdated
| } | ||
|
|
||
| if let Some(deb) = &self.debinfo { | ||
| !deb.exact_match |
There was a problem hiding this comment.
This would potentially show a lot more packages that we don't need to care about right now when uploading a new package/upgrading one. If Debian has a semver compatible crate available we currently stop because we can usually just use that and don't need to keep traversing the tree.
There was a problem hiding this comment.
This is sort of tricky. Crate A may make an API compatible update which introduces new dependencies. Hiding those gives a false sense of the work needed.
However, I guess we could say the new update doesn't matter since it's API compatible, so we just stick with the older version of the crate.
This is currently an area where debstatus is lacking, since we rely on how cargo is resolving dependencies, which is greedy. It may say we need a new version of a crate (which has the new dependency) when we really don't.
If we instead worked with Cargo.toml versions, we could provide a more accurate picture and I'd agree more with your stance.
There was a problem hiding this comment.
If Debian has a semver compatible crate available we currently stop because we can usually just use that and don't need to keep traversing the tree.
That's actually what my "This PR" image above shows, but then I made the change to use exact_match instead. I've changed the behavior now so that it only shows dependencies for a package in Debian if it's outdated/incompatible. This can be overridden with the "-a" switch.
jamessan
force-pushed
the
outdated-crates
branch
2 times, most recently
from
cb16c51
to
8512a72
Compare
Just because a crate currently exists in Debian doesn't mean we don't need the information about its dependencies. Especially in the case where there is significant version skew (outdated or incompatible), we should provide information about the dependency tree.
Signed-off-by: James McCoy <jamessan@jamessan.com>
When a crate is already packaged for Debian but is outdated, provide more information about this discrepancy. * Include "outdated" in the Debian information * Color the crate name as yellow, rather than green, since the package can't be used as is * Color the version as red
jamessan
force-pushed
the
outdated-crates
branch
from
8512a72
to
b5865cb
Compare
|
I just tested this, and to it seems like a clear improvement to my workflow. @kpcyrd what do you think about merging it? |
|
Fine with me 👍 |
With #32 merged, we now have more information to use when deciding how to display the dependency information.
Let's use this to provide more details when a crate is in Debian/NEW,but the package is incompatible with the current version of the crate being inspected.
In particular, we should display the dependency information for outdated/incompatible crates, since it's likely there have been changes. Also, provide more visual clues about the incompatibility -- crate names are yellow, rather than green/blue, "outdated" is included in the "(in debian" clause, and the version is red.
0.5.1:
After #32:
This PR:
