Hey there!

First of all I want to thank you for the enormous work you did for the community with this project! I love deps.rs and am using it quite often as a dashboard to visualize the dependency states of my or other projects.

But I came to notice that this project seems to be somewhat unmaintained right now - which is totally fine, everybody shifts their attention at one point or another to a new project or is unable to find the time to take care of the maintenance! But it would be a bummer to leave this out in the wild to rot. Would you consider opening the project up to the community or a volunteer - should one be found - to take this over?

I'm not saying that this specific person should be me (I'm not sure if I have the time required at hand) but it would be cool if the project would live on.

Now that a new team is forming to maintain the project I was wondering if we want to use some external service for communication to have a platform to discuss possible changes or ideas. What do you think about this? Would that make sense or do you think communication using issues & PRs is enough?

As for possible communication channels I can think of (in the order I prefer them):

• Matrix (easy to use and thanks to federation you probably don't need to make an account specifically for this if you already have one)
• Discord
• gitter.im (kind of dated by now but still preferred by some people)
• Mailing lists (just don't please)

Thanks to #96 I can now see what's going on in my cargo-udeps crate's report. Apparently it complains about CVE-2019-16760 which affects cargo versions 0.26.0 and below, but versions above are fixed. My cargo-udeps tool requires cargo versions ^0.50.0, so would never use 0.26.0 or below.

I guess the cause for this false positive is because cargo versioning is different from rust versioning. For rust version 1.n.0, the corresponding cargo version is 0.{n+1}.0. The CVE apparently expresses the bug in terms of the rust version, not the cargo version. Of course 0.27.0 or even 0.50.0 is below 1.27.0.

I'm not sure whether this is a bug with the rustsec database or with deps.rs. Pinging @tarcieri and @Shnatsel just in case.

As everybody knows already from #40, the project will now be maintained by everybody who wants.

I proposed myself to host it on deps.rm.rs but we could also take deps.rs. Please note that the price will be around $34. I don't personally want to pay for it by myself but I would agree on sharing the cost.

Please leave a comment if you prefer to keep deps.rs and pay for it or if it is okay to move it to deps.rm.rs.

(rm.rs is owned by myself. I started recently using it for https://yewprint.rm.rs)

Hi there,

The deps.rs site doesn't seem to be picking up new package releases (or at least some of them). For example, once_cell is coming up 1.9.0 rather than 1.10.0, and deno is showing 1.19.0 instead of 1.19.2.

Maybe the server process needs a restart?

We've had a good experience with actix-web using GitHub Actions but I see there's a travis config here already.

Lets spec out the goals for the CI, talking points:

• [ ] security audit
• [ ] tests
• [ ] deployments (stagings/prod)
• [ ] other

I've just released the new version 1.3.3 of my crate lingua. Deps.rs suddenly does not work anymore. In the past, there was never a problem with analyzing the dependencies and showing the correct badge in the README of the project. Can you tell what's wrong? Thank you very much.

https://github.com/pemistahl/lingua-rs

https://deps.rs/crate/lingua/1.3.3

I noticed that the dependency issue box presented at a project's status page may sometimes not present the most important information. In the example below, the project has 3 non-dev dependencies outdated, yet this box only reported the outdated dev dependencies.

As such, I propose with this PR to extend this box to also provide information about outdated main dependencies, in a way which does not occlude the other kinds of issues. I also fixed pluralization, so that a single bad dependency appears in its singular form.

Summary:

• replace render_dev_dependency_box with an extended render_dependency_box
  • reports insecure dev dependencies, outdated main dependencies, and outdated dev dependencies
  • handle pluralization in dependency count message
• change methods in AnalyzeDependenciesOutcome
  • add count_outdated
  • remove any_dev_issues, no longer used
• remove AnalyzedDependencies::any_dev_issues, no longer used

Data seems inconsistent:

https://deps.rs/repo/github/wez/wezterm and search for image; it shows the following:

image | ^0.23 | 0.23.12 | insecure

clicking through to image:

https://deps.rs/crate/image/0.23.12

everything there is green.

Bumps most dependencies to their latest versions and modernizes code to 2018 edition.

A non-goal of this PR is to update futures dependent crates to 0.3 ecosystem. I'm part way through doing it but it is about as much work to do as this PR.

This PR seems to retain the same capabilities of current deps.rs deployment. It's also clear that many more tests are needed.

Supercedes #42 & #31

For example https://deps.rs/crate/yukikaze would get me latest crate version While https://deps.rs/crate/yukikaze/status.svg would get me nowhere so user would need to always point to particular version which may not be convenient

Currently, inherited dependencies get ignored. For example, the blackbox and blackbox_decode crates in https://github.com/wetheredge/blackbox inherit tracing from the root, but it is missing from https://deps.rs/repo/github/wetheredge/blackbox.

Docs:

• https://doc.rust-lang.org/cargo/reference/workspaces.html#the-dependencies-table
• https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#inheriting-a-dependency-from-a-workspace

I might be able to take a stab at this in the next few days if it isn't already being worked on.

Related to: https://github.com/rust-disk-partition-management/gptman/pull/82#discussion_r873071638

We noticed that yanked dependencies do not seem to be reported at all. They're not necessarily vulnerabilities but they should be reported at least as outdated.

This can be observed in commit https://github.com/rust-disk-partition-management/gptman/commit/d7ca717f0a749e82dd9cad5f8c69efb1c6cb169c

It is important to note that:

1. crossbeam-utils is not a direct dependency of the project
2. it's only pulled for the binary of this crate and not the library

Possibly related to #109

In RustCrypto we have repositories with mixed editions (e.g. see the traits repo). To allow testing of MSRV we have temporarily moved 2021 edition crates into their own workspaces (e.g. see the kem crate). Unfortunately, deps.rs analyzes only the root workspace, so such crates are getting skipped as can be seen on the relevant page: https://deps.rs/repo/github/RustCrypto/traits

Right now, the badge url requires ../github/... Would like it to take ../github.com/.. as well. This is especially important for gitlab, where for example gitlab.freedesktop.org is not currently supported as far as I know.