Dependency and Reverse Dependency

[dstufft]

The new design has dependency and reverse dependency information. We'll want to implement this so that it shows up in the new design. One potential snag is that dependencies are specifiers which can match a range of versions... but we can only really display one version. I'm not quite sure what we should do there, maybe just display the latest that matches the specifier?

[nlhkabu]

Why not change the card a little... Instead of linking from the title, link from the version. Then add the additional versions to the card. i.e.:

<h3>Package Title</h3>
<p><a href="">v1.0</a>, <a href="">v2.0</a> and <a href="">v3.0</a> by <a href="">Author Name</a>

Or if there are a lot of versions (over 5???), we could do:

<h3>Package Title</h3>
<p><a href="">v1.0</a> to <a href="">v33.0</a> by <a href="">Author Name</a>

[dstufft]

That's fine with me!

Sent from my iPhone

On Nov 21, 2015, at 4:12 PM, Nicole Harris [email protected] wrote:

Why not change the card a little... Instead of linking from the title, link from the version. Then add the additional versions to the card. i.e.:

Package Title

v1.0, v2.0 and v3.0 by Author Name Or if there are a lot of versions (over 5???), we could do:

Package Title

v1.0 to v33.0 by Author Name — Reply to this email directly or view it on GitHub.

[dstufft]

One other thing to think of, is that we have some packages with missing dependency information... but we can't currently tell the difference between a package not having dependencies and our metadata just being incomplete. I'm not sure if we should do anything about this in the UI or not but our current dependency information is very... "fuzzy" might be the right word for it.

Projects might also have different dependencies depending on what file you download (like different for Windows vs OSX or something). It's actually fairly complex and I don't know what the right answer is for usably showing that information to people and what they actually care about (do they just care to get a general idea of what will be installed or do they want very specific data?).

[nlhkabu]

One other thing to think of, is that we have some packages with missing dependency information... but we can't currently tell the difference between a package not having dependencies and our metadata just being incomplete. I'm not sure if we should do anything about this in the UI or not but our current dependency information is very... "fuzzy" might be the right word for it.

So we know when a project has 'fuzzy' dependencies and when it does not?
If yes - then we should display a warning for 'fuzzy' instances (something like):

"Warning: some dependency data may be missing, or our metadata may be incomplete. Please check the dependency information on the package source."

Projects might also have different dependencies depending on what file you download (like different for Windows vs OSX or something). It's actually fairly complex and I don't know what the right answer is for usably showing that information to people and what they actually care about (do they just care to get a general idea of what will be installed or do they want very specific data?).

For this, how many variations should we expect?

If we're only talking about a couple of variations, we could use a button set to toggle between the variations:

Otherwise, if we expect more than 4(?), we could use a dropdown:

Each would require clear naming convention for each variation, and we would need to default to the most popular variation.

[dstufft]

We have two observable states within the database and here's what they could mean:

• We have dependency information in the database
  • It could be the full, accurate dependency information with markers (from https://github.com/pypa/interoperability-peps/pull/56) to indicate dependencies which are conditional on a particular property of the system (OS, Python version, Python Implementation, etc)
  • It could be a partial set of dependencies based on one particular environment but it may not accurately describe the dependencies on every platform.
• We could have no dependency information in the database
  • The project could just not have any dependencies.
  • The project could have dependencies and we just don't know it.

We can (obviously) determine the difference between the top level list items, but not between the sub items.

[nlhkabu]

Gah! What a nightmare! Ok, how about this:

We have dependency information in the database

"Warning! Dependency information is provided as a guide only and may be incomplete. Please check the package source for more information."

We could have no dependency information in the database

"Sorry, we do not have any dependency information for this package. Either:

• The package has no dependencies, or;
• The dependency data has not been submitted by the package owner.

Please check the package source for more information."

[dstufft]

That would work.

Oh, to make things a bit more complicated: At some point in the future we will be able to get to a point where we are more sure of whether or not we have accurate metadata or not so hopefully this can be a little bit of a legacy turd at some point.

[nlhkabu]

Sounds good :D Can you please give both divs the class of .notification-bar. Thanks!

[nlhkabu]

This entire tab will be commented out for launch (see #1309) - let's focus on getting this done after that :)

[brainwane]

In our meeting today we confirmed that, as a new feature, this isn't urgent enough to put into one of our early milestones.

[ChillarAnand]

Is anyone working on this issue?

[brainwane]

@ChillarAnand Sorry for the wait.

This is a complicated problem -- check out pypa/packaging-problems#54 to understand more about why. If you'd like to work on it specifically, please say so here and we'll see what a good first step would be. If you're looking for opportunities to contribute to Warehouse more generally, please check out these issues!

[brettcannon]

Just as reference/inspiration, GitHub now lists dependent packages: https://help.github.com/en/articles/listing-the-projects-that-depend-on-a-repository

[dstufft]

To be clear, GitHub's data is wrong-ish if I understand correctly. They're simply parsing requirements.txt and pipfile.lock and going "ok, everything listed here is a dependency". It'll be wrong in cases where that desn't line up 1:1.

Not bad to look at it from a perspective of UI and UX though.