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 https://github.com/DanielKeep/rust-custom-derive/commit/78e594baaea0a9e899d03afd6726a5ad105427ae

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 https://github.com/DanielKeep/rust-conv/pull/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 !

[smoelius]

Thanks again for your replies.

So, regarding the things we've discussed in this thread, is the following (from https://github.com/trailofbits/cargo-unmaintained/issues/279#issuecomment-2304454589) all that is still lacking?

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.

If so, then let me please ask the following. Suppose a dependency z is considered unmaintained, and that it appears in a package a like so:

z
└── y
    └── x
         ...
            └── c
                └── b
                    └── a

Would you consider b through z unmaintained? If you wouldn't, why not?

[jayvdb]

Yes, conv/custom_derive is the only aspect of this discussion which I think can still be improved. And thanks for the improvements so far. My output is getting close to matching what I expect.

Would you consider b through z unmaintained? If you wouldn't, why not?

Yes, I would, with one minor clarification that the chain of unmaintained would stop at whatever package is a part of the users workspace. i.e. both "a" and "b" might be in the same workspace, in which case "c" is the first which is unmaintained.

[jayvdb]

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

Just noting this wasnt correct ... the current crate lists https://codeberg.org/swsnr/gethostname.rs as the repo , still on codeberg.org , but a different username, not github.com , and even https://codeberg.org/swsnr/gethostname.rs.git is not a 404.

[smoelius]

Just noting this wasnt correct

Just to be sure I understand: the error message was not correct?

Does that message still appear today? If so, could you please give me steps to reproduce it?

I tried a couple things I thought might reproduce it (cargo unmaintained -p gethostname, cargo unmaintained -p tracing-bunyan-formatter), but I could not.

[jayvdb]

The error message was correct, at the time of gethostname v0.2.3. It no longer occurs as gethostname has been updated.

My link to github was wrong.

[smoelius]

The more I think about this, the less likely I feel I am to implement it.

Using the example from https://github.com/trailofbits/cargo-unmaintained/issues/279#issuecomment-2305799392, z would generate a warning for a. IMHO, generating warnings for b through y would just be additional noise.

So I am going to attach a "future enhancement" label to this issue.

I appreciate you raising it, though, along with all of the other feedback you've offered.