Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add dependency graph #1455

Closed

Conversation

@GuillaumeGomez
Copy link
Member

commented Jul 8, 2018

It'd be very useful to have a dependency graph so I made a small proof of concept:

screen shot 2018-07-08 at 13 38 13

screen shot 2018-07-08 at 13 36 55

I made it by only on front-end side but I think it'd be better to have done it in backend side directly instead (or at least provide an endpoint which would be called when the users want to see the dependency graph).

Any opinions? :)

@carols10cents

This comment has been minimized.

Copy link
Member

commented Jul 24, 2018

Woah. Interesting!

My initial impressions are:

  • What are the times when this would be useful? What problem is this solving?
  • What do the blue vs white dots mean?
  • What do the numbers that aren't version numbers mean? For example, I see "libc 0.2.42" near the top, then "libc 85248" in the next bunch-- what is 85248?
  • Is this only for the crates that the current crate depends on, or would you want it for dependent crates (the crates that depend on the current crate) too?
  • It's a little hard to read, and gtk doesn't even have that many dependencies 😆 I wonder how big this would be for, say, rocket... Is there a way to zoom in or navigate?
  • What would you want the backend to provide, if this was done on the backend instead? Would the user experience be different at all if the work was done on the backend?
  • Would you distinguish optional dependencies or dev dependencies?
@GuillaumeGomez

This comment has been minimized.

Copy link
Member Author

commented Jul 24, 2018

What are the times when this would be useful? What problem is this solving?

A bit every time. It doesn't solve any problem on its own but it allows someone to see how much dependencies a crate has. It comes from a debate I had a while ago where someone was saying that between two crates doing the same thing, he/she would take the one with the most (direct) dependencies. Of course I disagree with this statement. Another point is that, the more dependencies you get, the more failure "points" you have.

To put it more simply, it'd help people to realize that dependencies come with a "cost" (let's call it like that) and help them to pick a crate over another one on this criteria too.

What do the blue vs white dots mean?

Expanded/not-expanded iirc. But this is a proof-of-concept that I wrote quickly so nothing unexpected.

What do the numbers that aren't version numbers mean? For example, I see "libc 0.2.42" near the top, then "libc 85248" in the next bunch-- what is 85248?

The last entry point normally doesn't have its version determined so it's just version "id" (and again this is just a proof-of-concept).

Is this only for the crates that the current crate depends on, or would you want it for dependent crates (the crates that depend on the current crate) too?

Just for the current one even though we could add it to dependent crates too.

It's a little hard to read, and gtk doesn't even have that many dependencies laughing I wonder how big this would be for, say, rocket... Is there a way to zoom in or navigate?

Navigate yes, normally there are scrollbars (but I was on a mac so we don't see them). Zoom in no. But I know that some other libraries doing the same thing allow to zoom in.

What would you want the backend to provide, if this was done on the backend instead? Would the user experience be different at all if the work was done on the backend?

More information of course! 😄 I guess an entry returning all dependencies (and their own dependencies) would be perfect and would save a looooot of network calls. A backend call (so it's not loaded every time we arrive on a crate page, just when we want to see dependencies) that would return something looking like this:

"dependencies": {
  "gtk": {
    "version": "0.4.2",
    "optional": false,
    "dependencies": {
      ...
    }
  },
  "gdk": {
    ...
  },
}

Would you distinguish optional dependencies or dev dependencies?

Optional dependencies for sure. Not sure about dev dependencies: should we even have them in this tree? If yes, I suppose I could add checkbox "display dev-dependencies" and have them in a different color.

@GuillaumeGomez

This comment has been minimized.

Copy link
Member Author

commented Jul 24, 2018

Oh forgot to add: the backend callback would take the crate name and an optional version (if no version provided, we get the last version) as arguments so we can get specific version's dependencies as well.

@GuillaumeGomez

This comment has been minimized.

Copy link
Member Author

commented Nov 12, 2018

Any news about this?

@Eh2406

This comment has been minimized.

Copy link
Contributor

commented Nov 12, 2018

Does this use the same resolution algorithm as Cargo does? (commenting as I maintain it.)
Given that dependency resolution is NP-Hard, how do we keep it responsive? If we do it server side, how do we make sure it is not "denial of service as a service"?

@GuillaumeGomez

This comment has been minimized.

Copy link
Member Author

commented Nov 12, 2018

You already have the dependencies on server side. Couldn't you just return the dependencies full tree on demand?

@Eh2406

This comment has been minimized.

Copy link
Contributor

commented Nov 12, 2018

So for example, your screenshot above is not the resolution cargo will select. The screenshot has gtk 0.4.1 depending on gdk-sys 90786 but also has gtk 0.4.1 depending on gdk 90786 depending on gdk-sys 85260. There can only be one library linked with each external library so cargo will try different combinations of versions to select one that will build.

Cargo has logick like this for "the links attribute" (I.E. -sys crates), "unifying semver compatible versions", "the requested features being present", and will soon have "unifying public dependencies". (for some definition of soon.)

It could be that we are Ok with this being different then Cargos algorithm, in which case we need to find a way to make that clear in the UI. It could be that we can find a way to use Cargos implementation directly, (It is very fast in practice, if I do say so myself,) but then we need to do some work to extract the code and protect the server from some attacker finding a slow case before I do. We could make a new implementation that is optimized for crates.ios use pattern, which would be useful for differential fuzzing with the current implementation, and would be a lot of work.

@GuillaumeGomez

This comment has been minimized.

Copy link
Member Author

commented Nov 12, 2018

Instead of trying to have a beautiful tree with common crates put in common, we could just return the list of dependencies for all dependencies. Then the JS can make it look it better.

@Eh2406

This comment has been minimized.

Copy link
Contributor

commented Nov 12, 2018

True, we can make it pretty on the front end. I was interested in what shud be displayed. The info you are displaying will not match what Cargo will use. Getting the list that Cargo will use, is not computationally eazy.

@carols10cents

This comment has been minimized.

Copy link
Member

commented Jan 14, 2019

Given the issues that @Eh2406 pointed out, I'm going to close this. We're having enough trouble maintaining the features crates.io has now, and we don't have the bandwidth to maintain new features that might be confusing if they're not exactly right. Thank you for your work, though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.