Fallback to getting repository from latest version of crate

[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

[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

[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.

[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 #279 (comment)) 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.