Home: Package applicability in NuGet package manager
Status: Reviewing
The specification is available here:
Package applicability in NuGet package manager UI
The prerequisite for this issue is https://github.com/NuGet/NuGetGallery/issues/3098. The implementation will start server side.
Client side discussions should happen on this issue.
This issue covers,
- PM UI applicability.
- add package applicability.
- list package --outdated applicability. See linked issues.
[To help searching for this issue: "Search by TFM" and "Update by TFM"]
anangaur
All 21 comments
Just some random thoughts having had this thing in a mind background thread.
A first question would be: will this be a server-side or client-side thing? Or, as I would expect, both sides?
Package metadata does not contain the relevant info required to make a decision whether to include/exclude a result, so this should be based on telemetry. Ideally, this telemetry is something that can be collected by all NuGet clients, e.g. NuGet.exe, dotnet.exe, VS, Rider, Paket, ...
Ideally the format of this telemetry is a protocol extension (given this client-side SearchContext, fetch me my results!) where every client can build such a search context and contribute data as it sees fit (e.g. project type, target framework, ...)
The server can then use this context (ideally with a well-known decision tree?) and gather results that best match the query and search context.
And then of course the other one to consider: privacy. What info can be legally shipped to the server to come up with a better result?
maartenba
on 9 Aug 2017
With the spec now announced: see previous comment :-)
maartenba
on 14 Sep 2017
(or: what is the Server-Side spec for this?)
maartenba
on 14 Sep 2017
@maartenba this spec is focused on the end-user experience. Once we are close to finalizing that, we'll start a discussion around the implementation details.
karann-msft
on 14 Sep 2017
Thanks! Looking forward to seeing the technical spec later on.
maartenba
on 15 Sep 2017
@karann-msft there are some asks on having the framework information on gallery too. Can you include that in your spec? If not, create a sibling spec that takes care of the gallery changes and search improvements both on the gallery and on VS UI.
anangaur
on 13 Oct 2017
Based on the current proposal for GT, it'll need to consider the new package type as well. So tools would not get shown in the PM UI.
https://github.com/NuGet/Home/wiki/Global-Tools---NuGet-Implementation
Name still a subject to change, but want to make sure it's tracked.
nkolev92
on 14 Dec 2017
@nkolev92 I don't think there would ever be a reason for GT packages to show up in PM UI, correct? Since they are not meant to be installed to project?
karann-msft
on 18 Dec 2017
@karann-msft Yeah, that's what I meant.
I've updated the comment to say "Name still a subject to change" cause I assume that was the confusing part?
nkolev92
on 18 Dec 2017
@nkolev92 I will update this spec to call out that Tools packages will never be shown in the PM UI, but this should be tracked as part of the GT spec since GT packages are never applicable or compatible with any project and we should safeguard against it.
karann-msft
on 19 Dec 2017
@karann-msft Yep, that's already called out in the tools spec and implemented as such :)
A similar ask came through https://github.com/NuGet/Home/issues/6484.
We should consider the handling of the MSBuildSdk package type in search based on the decisions in that issue.
No "actionables" here yet, before we narrow that down.
nkolev92
on 7 Feb 2018
Figured I'd chime in here instead of creating a new issue.
I'd love to have a type parameter on the search and autocomplete web APIs so MSBuild intellisense can provide correctly filtered suggestions for SDKs and tools.
mhutch
on 27 Feb 2018
Similarly to DotnetTool, when implementing Package Applicability should account for the package types chosen for the runtime/targeting packs. #7337
nkolev92
on 17 Jan 2019
Have we decided upon the name of the packageType for these scenarios?
anangaur
on 17 Jan 2019
@anangaur No, I kicked the tires on that discussion, before commenting.
I wanted to make sure that it doesn't slip through the fingers.
nkolev92
on 17 Jan 2019
The package types in question are:
DotnetTool and DotnetPlatform.
The Framework Reference feature also introduces other considerations.
https://github.com/NuGet/Home/wiki/%5BSpec%5D-FrameworkReference-in-NuGet
nkolev92
on 5 Apr 2019
Note> Update by TFM has a good scenario in AzDO bug 745617 - create a netcore 2.1 project that uses this package: https://www.nuget.org/packages/Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore
You'll be suggested an update (via update tab) to 3.0.0 versions of this package, despite the fact that the TFM in the new package is only netcoreapp3.0
rrelyea
on 16 May 2019
This would be quite useful, especially with the recent release of .NET Core 3.0 packages. The PM UI offers to upgrade the EntityFrameworkCore packages, but they are only compatible with .NET Standard 2.1 while my projects still target .NET Core 2.2.
Additionally, after reviewing the user experience spec, I would offer a couple of additional suggestions for the Updates scenario.
1 - Icon for available, but incompatible, updates
The spec indicates that when opening the PM UI, the number displayed next to Updates should indicate the number of compatible updates available. It would also be useful to have an additional icon if incompatible updates are detected.
2 - Ignore specific package version
A user should be able to ignore a specific available version so that the PM UI doesn't continually suggest updating to it. It would be great if this info could be stored in the project file or otherwise shared with a team. I understand this scenario might be out of the scope of this issue -- perhaps it would be better suited as a separate feature suggestion?
HolisticDeveloper
on 24 Oct 2019
Great feedback @HolisticDeveloper 馃憤 As we iterate on the spec and finalize it, these will definitely come in handy.
anangaur
on 24 Oct 2019
Better late than never, @mhutch 馃槃?
Figured I'd chime in here instead of creating a new issue.
I'd love to have a
typeparameter on the search and autocomplete web APIs so MSBuild intellisense can provide correctly filtered suggestions for SDKs and tools.
We have a package type parameter in the search and autocomplete APIs allowing you to filter to a specific package type, e.g.
https://azuresearch-usnc.nuget.org/autocomplete?q=azure&packageType=dotnettool&semVerLevel=2.0.0&prerelease=true
Package applicability (a.k.a. search by TFM) will likely take package type into account but will require additional parameters from the client, e.g. project framework.
joelverhagen
on 27 Jul 2020
Note> Update by TFM has a good scenario in AzDO bug 745617 - create a netcore 2.1 project that uses this package: https://www.nuget.org/packages/Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore
You'll be suggested an update (via update tab) to 3.0.0 versions of this package, despite the fact that the TFM in the new package is only netcoreapp3.0
This is happening again with the netcore 3.1 -> net 5.0 especially with the ASP.NET packages which are locked to a TFM.
Right now I have to search through the VS nuget client update list for packages I want to update, because I must ignore all the ASP.NET packages which are not compatible.
joemey
on 8 Dec 2020
Related issues
vsfeedback
路
3Comments
jainaashish
路
3Comments
philippe-lavoie
路
3Comments
blackchoey
路
3Comments
rrelyea
路
3Comments
Most helpful comment
This is happening again with the netcore 3.1 -> net 5.0 especially with the ASP.NET packages which are locked to a TFM.
Right now I have to search through the VS nuget client update list for packages I want to update, because I must ignore all the ASP.NET packages which are not compatible.