If X depends on an unmaintained package, should X be considered unmaintained?

[jayvdb]

I have the following dep tree

│   ├── tracing-bunyan-formatter v0.3.9
│   │   ├── gethostname v0.2.3

and the result is:

gethostname (https://codeberg.org/flausch/gethostname.rs.git does not exist)

because that is its old repo, and doesnt exist any more.
The latest crate is v0.4.3 and it correctly lists the current repo as https://github.com/swsnr/gethostname.rs

[smoelius]

I've run into this problem myself. This is what prompted me to write this section in the README: https://github.com/trailofbits/cargo-unmaintained?tab=readme-ov-file#known-problems

I have resisted fetching the most recent version of a package because (1) it requires additional network traffic and (2) cargo-unmaintained is already slower than I would like.

I'm open to suggestions here. But the tradeoff seems to me to be: live with a few spurious warnings vs. make cargo-unmaintained slower overall.

Do you see the problem differently?

[jayvdb]

Well, I found this awesome project due to comments on https://www.linkedin.com/posts/endlermatthias_rustlang-rust-activity-7210892404172750848-Pdwx/ , and many of the comments there are strongly suggesting these checks should be automated, but cargo-unmaintained can not be automated if is has false positives.

I'd take accuracy & automatability over speed any day.

If I put in the effort to remove the unmaintained crates from my deps list, which will not be easy as this tool has highlighted some deeply nested deps which are a problem, then I want to automatically force that the list stays clean there-after.

The first run of cargo-unmaintained does take a while, but it looks like it already has good caching on subsequent runs.
So then the challenges are a) keeping the user informed during the first run, so they dont cancel, and b) informing them where the caches are so they don't accidentally delete it.

[jayvdb]

I found another two in my mono-repo

tracing-opentelemetry (not in https://github.com/tokio-rs/tracing)
rand_hc (not in https://github.com/rust-random/rand)

https://crates.io/crates/tracing-opentelemetry now has a repository set to https://github.com/tokio-rs/tracing-opentelemetry

https://crates.io/crates/rand_hc now has a repository set to https://github.com/rust-random/rngs

[smoelius]

I have resisted fetching the most recent version of a package because (1) it requires additional network traffic and (2) cargo-unmaintained is already slower than I would like.

I realized that I was thinking about this wrong. cargo-unmaintained can check only the packages that it intends to report as unmaintained. That reduces the number of false positives. Moreover, it doesn't significantly affect performance, because the check is performed for only a small fraction of the packages.

I implemented this in #339 and just released that change with version 1.4.0. Please let me know if this is not what you were asking for.

[jayvdb]

We've upgraded our opentelemetry stack, so many of the above problems have been resolved due to that.

However I still see this one, which was mentioned above

rand_hc (not in https://github.com/rust-random/rand)

rand_hc comes from:

> cargo tree --invert rand_hc --target all
rand_hc v0.2.0
└── rand v0.7.3
    └── http-types v2.12.0
..

IIRC, rand_hc is only a dep for wasm target.

Also output

custom_derive (not in https://github.com/DanielKeep/rust-custom-derive)

Here is where that is coming from:

> cargo tree --invert custom_derive
custom_derive v0.1.7
└── conv v0.3.3
..

[smoelius]

Thanks very much for your replies.

Re rand_hc: could I trouble you to run a test for me? Could you please try:

rm -rf $HOME/.cache/cargo-unmaintained

And then repeat the above experiment and see whether the problem persists?

Aside: If I recall correctly, you are running cargo-unmaintained on a private repo. If it's possible for you to reproduce an issue with the -p flag, that would be very helpful. For example, when I run cargo unmaintained -p http-types, I see this:

http-types (https://github.com/http-rs/http-types updated 673 days ago)
    base64 (requirement: ^0.13.0, version used: 0.13.1, latest: 0.22.1)
    cookie (requirement: ^0.14.0, version used: 0.14.4, latest: 0.18.1)
    infer (requirement: ^0.2.3, version used: 0.2.3, latest: 0.16.0)
    rand (requirement: ^0.7.3, version used: 0.7.3, latest: 0.8.5)
    serde_qs (requirement: ^0.8.3, version used: 0.8.5, latest: 0.13.0)

---

Re custom_derive: is that report not correct? From what I can tell, there is no package named custom_derive in DanielKeep/rust-custom-derive:
https://github.com/search?q=repo%3ADanielKeep%2Frust-custom-derive+%22%5Bpackage%5D%22&type=code

[jayvdb]

Re rand_hc I did that rm and I still see

rand_hc (not in https://github.com/rust-random/rand)

And I get the same output as you for this

> cargo unmaintained -p http-types
http-types (https://github.com/http-rs/http-types updated 673 days ago)
    base64 (requirement: ^0.13.0, version used: 0.13.1, latest: 0.22.1)
    cookie (requirement: ^0.14.0, version used: 0.14.4, latest: 0.18.1)
    infer (requirement: ^0.2.3, version used: 0.2.3, latest: 0.16.0)
    rand (requirement: ^0.7.3, version used: 0.7.3, latest: 0.8.5)
    serde_qs (requirement: ^0.8.3, version used: 0.8.5, latest: 0.13.0)

---

Re custom_derive , yes "not in https://github.com/DanielKeep/rust-custom-derive" is correct, and useful to know, but .. it is the correct repo, and can be found when using the respective tag https://github.com/DanielKeep/rust-custom-derive/blob/v0.1.7/Cargo.toml .

Renamed at DanielKeep/rust-custom-derive@78e594b

Also, consider what the user in this scenario would want to know about the problem ... ?

It is useful to know that custom_derive v0.1.7 is the latest version on https://crates.io/crates/custom_derive , that it is 8 years old, and that conv v0.3.3 (also latest and 8 years old) is a contributor to this problem.
The user should be trying to replace conv or improve it like DanielKeep/rust-conv#14

[smoelius]

I'm going to have to think about the rand_hc issue. It's not obvious to me what is going wrong.

Also, consider what the user in this scenario would want to know about the problem ... ?

It is useful to know that custom_derive v0.1.7 is the latest version on https://crates.io/crates/custom_derive , that it is 8 years old, and that conv v0.3.3 (also latest and 8 years old) is a contributor to this problem. The user should be trying to replace conv or improve it like DanielKeep/rust-conv#14

In your mind, what would the ideal report for custom_derive look like?

[jayvdb]

My guess is the rand_hc problem is related to it being a dependency for a target not in use.
It is enscripten target https://github.com/rust-random/rand/blob/0.7.3/Cargo.toml#L77-L78

In your mind, what would the ideal report for custom_derive look like?

IMO it would like it to report (in red) something like:

conv (https://github.com/DanielKeep/rust-conv updated 8 years ago)
custom_derive (https://github.com/DanielKeep/rust-custom-derive/tree/v0.1.7 updated 8 years ago)

Note conv is currently not listed in the output of unmaintained for me.
i.e. any crate which depends on custom_derive for a while is also unmaintained, because custom_derive is not maintained.

[smoelius]

One more question re the rand_hc issue: do you see this in your output?

aes-soft (not in https://github.com/RustCrypto/block-ciphers)*
aesni (not in https://github.com/RustCrypto/block-ciphers)*
cpuid-bool (not in https://github.com/RustCrypto/utils)*
crypto-mac (not in https://github.com/RustCrypto/traits)*
ctr (not in https://github.com/RustCrypto/stream-ciphers)*
...
* a newer version of the package is available

[jayvdb]

I dont see any of those.

[smoelius]

I dont see any of those.

That's curious to me. When I create a dummy package with just one dependency, http-types, and run cargo-unmaintained on it, I see that.

Full output

http-types (https://github.com/http-rs/http-types updated 673 days ago)
    base64 (requirement: ^0.13.0, version used: 0.13.1, latest: 0.22.1)
    cookie (requirement: ^0.14.0, version used: 0.14.4, latest: 0.18.1)
    infer (requirement: ^0.2.3, version used: 0.2.3, latest: 0.16.0)
    rand (requirement: ^0.7.3, version used: 0.7.3, latest: 0.8.5)
    serde_qs (requirement: ^0.8.3, version used: 0.8.5, latest: 0.13.0)
stdweb (https://github.com/koute/stdweb updated 1777 days ago)
    rustc_version (requirement: ^0.2, version used: 0.2.3, latest: 0.4.0)
stdweb-derive (https://github.com/koute/stdweb updated 1777 days ago)
    syn (requirement: ^1, version used: 1.0.109, latest: 2.0.75)
stdweb-internal-macros (https://github.com/koute/stdweb updated 1777 days ago)
    sha1 (requirement: ^0.6, version used: 0.6.1, latest: 0.10.6)
    syn (requirement: ^1, version used: 1.0.109, latest: 2.0.75)
aes-soft (not in https://github.com/RustCrypto/block-ciphers)*
aesni (not in https://github.com/RustCrypto/block-ciphers)*
cpuid-bool (not in https://github.com/RustCrypto/utils)*
crypto-mac (not in https://github.com/RustCrypto/traits)*
ctr (not in https://github.com/RustCrypto/stream-ciphers)*
time-macros-impl (not in https://github.com/time-rs/time)
proc-macro-hack (https://github.com/dtolnay/proc-macro-hack archived)

* a newer version of the package is available

You're sure you're running version 1.4.0?

$ cargo unmaintained --version
cargo-unmaintained 1.4.0

[jayvdb]

You're sure you're running version 1.4.0?

gosh sorry, no, somehow I was still using 1.30. Re-running now, but also heading to bed as it takes a while to run. Will report results tmr.

[smoelius]

gosh sorry, no, somehow I was still using 1.30.

No problem at all.

Re-running now, but also heading to bed as it takes a while to run. Will report results tmr.

Thanks!

[jayvdb]

I now see the same fot http-types, and rand_hc has disappeared !