Something like js = {package = "mozjs", version = "0.9.3"} should not say the crate depends on js. This is visible on servo/servo

When viewing a repo that has outdated dependencies, display a button to to update the dependencies.

If the user is not logged in, the button should prompt the user to log in.

When logged in, clicking the button should prompt the user to select the dependencies they wish to update. Confirming this prompt, we should then draft a PR for the user to submit which updates the selected dependencies.

Not sure when it started, but since some time, it's showing a "dependencies unknown" badge and if you visit the site, you are getting a "Failed to analyze repository" error. I can observe it on all of my own projects I've tried and it seems that this repo's deps.rs badge is affected too.

Use Host and X-Forwarded-Proto request headers to figure out the base url.

I used this on my repo here: https://github.com/fschutt/printpdf - the dependencies are up to date, but the color of the badge doesn't really reflect that, it's not green like I'd expect it to be. I would use different colors for up-to-date vs outdated.

I've seen that deps.rs also supports repository URL's in addition to published crates. However at the moment on a crate's dashboard there isn't a link to repository status (and vice-versa).

For example I have the following published crate and related repository:

• https://deps.rs/crate/vonuvoli-scheme/0.0.6
• https://deps.rs/repo/github/volution/vonuvoli-scheme

It would be nice to have on each of these dashboards a link to:

• the latest published crate dashboard;
• the repository dashboard;
• a list of previous releases dashboards; (if one needs an older version of a crate an wants to asses its dependencies;)

Hi, I have two public repo in this GitLab group.
One works fine with derps api-swgoh-gg but the other not swgoh_farming_bot

The first is a library do Cargo.lock is not in git but the second is a binary so there is a Cargo.lock.
I understand what is wrong.

Thanks for this great site.

Flat square styled badges would be a great addition in my opinion, just like the one on shields.io.

https://github.com/aatxe/irc/blob/stable/Cargo.toml

Currently we return an dependencies: unknown badge for all sorts of errors. I think it would be nice to make the errors more transparent such as dependencies: parse error or at least just dependencies: error to differentiate between internal errors (which are our fault) and external errors (which are the users fault).

I'm just not sure how the error badge should look like right now.

The https://deps.rs homepage appears to be down:

For example getrandom has the following Cargo.toml, but on its page only log crate is shown.

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

What should happen to outdated build dependencies? Should they be excluded from the badge?
@Enet4 correctly noted that issues with the build-time dependencies could in the worst case lead to secret credentials being leaked during the CI/CD workflow, so they may be relevant to some people.

As @robjtede suggested, we could make the inclusion of build dependencies in the badge opt-in, but the question would be how. You could use a GET parameter in the URL to enable/disable this but that would require some explanation from our end and may not be very intuitive to use. Example for this:

https://deps.rs/repo/github/deps-rs/deps.rs?build_deps=false

What do you guys think? How could a good solution work?

As we just discussed in #44, the project is currently running on a Nightly toolchain. There's nothing wrong with that, but to avoid having a broken build out of nowhere we should either lock on a specific nightly version that is guaranteed to work or look into whether we can somehow move to stable easily.

I'm going to take a look and see how extensive the use of nightly-only features is.

Should also work for non-workspace multi-crate repos. Could use code search to find all Cargo.toml files.

It would be extremely useful to be able to view also the status of transitive dependencies (i.e. dependencies of dependencies, and so on...) (Perhaps this would be a second dashboard with more data pertaining to the "freshness" of a crates whole dependency tree.)

Because at the moment the "green" status of a crate might give the "false" impression of "up-to-date" status, especially with regard to security implications.

For example it might happen that a direct dependency of my crate was abandoned, thus receiving no updates. Moreover it might happen that the depenency in question depends itself on other crates which have been updated in the interim. However my dashboard is green, although if taken on the whole I depend (transitively) on an "ancient" crate.

Moreover, still on this subject, perhaps another "freshness" metric could be determined by taking into account the "age" of a crates direct and transitive dependencies, like for example the 25% percentile of longest ages (stating that 25% of the dependencies are older than that), or the reverse the 75% percentile (stating that 75% of the dependencies are newer than that).

Perhaps taking into account how many open issues (or even better closed issues) a given crate has taking into account direct and transitive dependencies.

For example the Chariot repo has many sub-crates but deps.rs currently only generates a single badge.

Ideally every crate would get a badge.

ref: https://www.reddit.com/r/rust/comments/7wvus2/announcing_depsrs_dependency_status_reports_and/du3sils/

Just for tracking

For now, we get latest version of crate via HTTP call, each crate cost a HTTP call, which might be expensive.

If we keep a full index local cache, and timing sync it, that might be cheaper and faster.

Here are my ideas:

1. Download github archive file every 5 mins and load everything in memory, for now, crates.io-index archive file is 35MB.
2. Clone and read via git2 crate, incremental synchronization every 1 min.
3. Download archive file when first launch, incremental synchronization via github api

In may just be reading this wrong but wanted to report what I saw

Would it make sense to not show outdated dev-dependencies on the badge?

It makes the crate seem to be outdated even if it is only for dependencies used to generate tests/benchmarks.

When going on https://staging.deps.rs/repo/github/rusoto/rusoto it is possible to get a "Failed to analyze repository" error.

On deps.rs it takes about 1 second to load from a cold cache but it always works. On staging.deps.rs when it fails it does so immediately.

Both were running on the same version.

cc @paolobarbolini

Related to #66 but covers overall caching policies instead of details about just cargo index caching.

We need to consider what our stale-ness tolerance is, especially for the SVG badges (worst case), since I gather than plan will be running a caching CDN in-front of the service. The maximum staleness time will always be the sum of all cache TTLs.

I think ideally, it should be no longer than 1 minute from the time the live crates index is updated to the time a badge is updated.

An sample proposal:

Cargo index cache update time:          20 seconds
Crate query (from cached index) TTL:	10 seconds
SVG Max-Age / CDN TTL:                  30 seconds
==================================================
Total (worst case update time):         60 seconds

I use [patch.crates-io] to override the crate used in my project when I make a bug fix that is waiting to be upstreamed.
However this results in a higher version then is listed on crates.io causing the deps.rs listing to say "out of date", when it should really say "up to date".

Occurs on vulkano-win here: https://deps.rs/repo/github/rukai/pf_sandbox

I've got a two year old repo that shows as up to date:

This is because the deps are specified like:

[dependencies]
gtk = "^0"
hyper = "^0"

But the lockfile shows the deps are actually locked to much older versions:

dependencies = [
 "gtk 0.0.7 (registry+https://github.com/rust-lang/crates.io-index)",
 "hyper 0.9.7 (registry+https://github.com/rust-lang/crates.io-index)",
]

https://github.com/rustsec/cargo-audit

It might make sense to use the underlying libraries behind cargo-audit instead of it directly.

Processing https://github.com/getsentry/symbolic/blob/master/Cargo.toml results in a failure.

Needs a re-think. The remnants of the old method (which is incompatible with modern futures system) are left commented for reference.

See #53 (comment).

It looks like semver 0.11 doesn't support parsing exact versions anymore, which lead to us downgrading it to 0.10 in #60

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

• UI component on details page to select branches of the repository
• query param option for the status endpoints to select branch

Similar to docs.rs, it'd be nice to have a report for packages on crates.io.

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)

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.

A workspace can have "glob" members, like in this example from servo:

[workspace]
members = [
    "ports/servo",
    "tests/unit/*",

    "ports/geckolib",
    "ports/geckolib/tests",
]

Currently paths ending in * are filtered out (see b0c77b4), but ideally we'd find a better way to support those.

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)

Continued from #48.

We are waiting for a release of maud which does not require a nightly toolchain. This may happen soon, according to lambda-fairy/maud#219. Alternatively, we could fetch the upstream version directly from the repository.

At the moment when an insecure crate is listed there's no easy way of knowing what's the security vulnerability and which versions are effected.

This could be implemented by making the button into a link.