Nugetgallery: Show dependent packages for a given package on the details page

[anangaur]

We should show dependent packages on the details page. Proposal:

By default collapsed:

On expand show 20 and Show all option:

Clicking on the "Dependents header" or "Show all" takes to package search page that shows all the dependents

[NickCraver]

I agree this would be very useful. Here are some examples of where third-parties are doing this (in ways that are really hard to navigate for popular packages) today:

• NuGet Must Haves: http://nugetmusthaves.com/Dependency/Dapper
• Libraries.io: https://libraries.io/nuget/Dapper

Note that the feed in Phil Haack's old post doesn't work for many dependencies: https://packages.nuget.org/v1/FeedService.svc/Packages?$filter=substringof(%27Dapper%27,%20Dependencies)%20eq%20true&$select=Id,Dependencies (it stops midway through the As, alphabetically).

[robertmuehsig]

I'm not sure if this "Tag-cloud" dependents visualization is helpful at all. Maybe make it as a list like the normal package-list-visualization and if someone want "See all" he lands on the search page - that would be nice.

[anangaur]

@robertmuehsig The tag cloud of dependent packages will help if we sort them by popularity so that a glance may tell you the important packages taking dependency on it, if any.

[RichiCoder1]

Would def like this. I would add that it'd be great for dependencies to be in order of their own popularity. Would the Dependents also list indirect dependents? If not, would be nice to see that count.

[skofman1]

In addition, when we build this, we should have an API allowing third parties to query this information.

[sanjuroo]

its year 2019, why is this not implemented yet?

[loic-sharma]

@sanjuroo We're currently reworking our search infrastructure (see https://github.com/NuGet/NuGetGallery/issues/6371). This rework is a large effort that will take some time, but it should enable us to implement this feature. I've made a prototype of this here: https://github.com/loic-sharma/BaGet/blob/master/src/BaGet.Azure/Search/AzureSearchService.cs#L138

[chgill-MSFT]

Howdy! I'm happy to announce we currently have a spec in review 🎉 Please leave any feedback you might have!

Spec announcement: https://github.com/NuGet/Announcements/issues/43
Spec: https://github.com/NuGet/Home/wiki/Showing-dependent-packages-on-NuGet.org-(Used-By)

[chwarr]

The [spec] defines a dependent package as one for which the "Latest stable version depends on any version of the focus package."

Has there been any consideration of whether or not a package depending on an unlisted version of the focus package should be considered a dependent?

[karann-msft]

What happens if the latest version of the package which was the first time it depended on the focus package gets soft deleted?

PS - love the PM art @chgill-MSFT :)

[loic-sharma]

Has there been any consideration of whether or not a package depending on an unlisted version of the focus package should be considered a dependent?

I believe the UI will show the latest listed stable version that depends on any version of the focus package.

What happens if the latest version of the package which was the first time it depended on the focus package gets soft deleted?

I believe that deleted package will no longer be shown on the focus package's "Used By" list, regardless of whether it was soft or hard deleted.

@dcc7497, @chgill-MSFT, @joelverhagen please correct me if I said anything incorrect :)

[chgill-MSFT]

Has there been any consideration of whether or not a package depending on an _unlisted_ version of the focus package should be considered a dependent?

@loic-sharma I think this is referring to the case where the latest stable version of a dependent is depending on an unlisted version of the focus package, so the focus package is the unlisted one here.

@chwarr That's a great question I should add to the FAQ! We have considered that case, and our design will still show the dependent in question as a dependent in the UI. The same is true in the case that the depended-on version is deprecated. This is for a couple reasons:

1. Technically, depending on an unlisted version of the focus package doesn't void the "endorsement." Unlisting is a choice from the focus package owner, but the "Used By" display is supposed to showcase our best understanding of the current dependent author's judgement.
2. Making any part of this feature specific to the focus package version gets pretty complex without necessarily adding any clarity or additional value. Keep in mind that, at restore time, the version of a dependency a package _actually_ uses can vary for several reasons.

Is there a particular reason you're interested in this scenario or feel it may impact your experience with the feature?

[chwarr]

@chgill-MSFT, nothing concrete, beyond a vague "Will this make it harder for package maintainers to move people along to newer versions of packages?". Your reasons make sense here, and since the current plan is to omit the depended upon version, I don't think that will set back the package maintainer. LGTM.

I'm assuming that when a package maintainer unlists or deprecates a package, they're implicitly saying "You probably don't want to use this version." I know that there are other reasons to unlist/deprecate, but I suspect the majority are to point people at other versions.

When I was maintaining a popular NuGet package, we had a bear of a time getting people to use a version that had been released in the past 2 years, let alone inside the window that we had the resources to support. A common response to support questions was "Oh, we added that feature 18 months ago. Try the current version." If the most popular version of our package had been highlighted, we would have had even more trouble than we did.

[ncook-hxgn]

This looks cool - any chance it will make an appearance in Azure DevOps Artifacts Feeds? That would be hella sweet!

[joelverhagen]

Thanks for the encouragement, @ncook-hxgn! This repository (NuGet/NuGetGallery) is just for nuget.org and the code that runs Azure DevOps is owned by another team. Hey, @anangaur perhaps you know the best way to provide Azure DevOps feedback?

[anangaur]

@ncook-hxgn , You can raise a request here for AzDo Artifacts Feeds: https://1esideas.powerappsportals.com/community/forum/46102c9c-6b49-ea11-a812-000d3a579c35

[ncook-hxgn]

Thanks for the direction @anangaur, will do :)

Edit: @anangaur it seems like that link is for Special Microsoft folks.. I'm unable to access it. Do you have a github link for mere mortals or something of that ilk, where I could ask for this?