-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Should runtime.
packages be listed in NuGet.org?
#7568
Comments
This is an area where I think improved NuGet support would be better. These Ideally, NuGet would have first class support for these types of "sub-packages" and would have a more general way to |
+100 Soft RID-specific dependencies would be awesome. Like, if I'm doing For clarity, the following packages doesn't use that feature, right? https://www.nuget.org/packages?q=Microsoft.NETCoreApp.Runtime It's System.IO.Ports that does. Yes? |
For
|
We on NuGet.org have thought somewhat about this problem and, I believe, the core issue extends beyond For example, a package like Generally, NuGet.org's current approach is that certain default views filter some "implementation detail" packages out. This has effect in a couple of places:
So, in short, there is some notion already in NuGet.org that some packages are not as interesting as other for list views. The being said, I strongly believe that any listed package should be visible if you search for the package ID. So if someone searches For a search of less than the exact package ID (like We do have a way to "transfer popularity" (https://docs.microsoft.com/en-us/nuget/nuget-org/deprecate-packages#transfer-popularity-to-a-newer-package) of packages on NuGet.org which essentially moves download counts from an old package to a new package for search ranking purpose. This feature could reasonably be extended to completely nullify the download counts on a package making it appear at the bottom of the search results unless an exact match is found. It's up to the package owners whether they want to mark a package as listed. However, unlisting a package may signal the wrong intent: it might make user's think it's deprecated or should not be used for any reason.
@tannergooding, yeah this makes a lot of sense. This will immediately become complex with transitivity but I think it's a feature request worth proposing over on NuGet/Home. For anyone interesting, feel free to use our proposal process: to structure the conversation: https://github.com/NuGet/Home/tree/dev/meta#nuget-proposal-process. I think there is some overlap here in the I think to prioritize such a feature we would need to understand the impact of not implementing this feature (i.e. status quo). Are there users getting confused and using these packages directly? Are there package searches which causing users pain because they are crowded with uninteresting packages? |
There are at least three topics here (some which are overlapping):
The problems with runtime packages today is searching on them is effectively useless. I was searching on them and the results are not meaningful. This conversation started because a researcher asked me about it. It raises a bigger question of how we offer transparency on runtime packages. It would be awesome if these packages were easy to inspect but not noisy. They are this fully separate category and scenario of packages on NuGet.org. For example, it would be good if dotnet publish told you which package it downloaded for you (in some reasonable way) and then you could inspect it in the NuGet gallery. That would be a good supply chain measure. I am can write up some proposals. |
The runtime.json packages are "packages with native dependencies". The "runtime" searches are just a tip of the iceberg. The searching problem should be solved for the most common cases already as @joelverhagen explained. I do not think that it makes sense to further optimize searching experience for runtime.json packages as they exist today. We should rather focus on the end-to-end experience for packages with native dependencies in .NET. NuGet/Home#9631 has an example of what this may involve.
For packages with native dependencies: The interop with native code (OS or 3rd party libraries written in C/C++) has always been a .NET strength. The impact of not implementing this feature is erosion of this strength. |
Another existing feature that we could consider using here with some thought would be packaged types. Currently .net tools, templates, SDK packages all use a special package type, which means that you can get a filtered view on nuget.org and can search within that. We would need to make sure it plays nice with restore. But this is the point of package types. A .nuspec field that allows package authors to declare a special case for their package that exceeds or is somehow different than a standard dependency package. |
/cc @directhex @steveisok |
I'm still playing with the idea of switching to RID-specific apps by default (for .NET 8): dotnet/sdk#23540. It occurs to me that if we made that change, that enabling restore of just one RID slice would enable fundamental improvements as a default experience (for apps that have RID-specific dependencies). In short, the restore code (on the client and server) would be significantly less. I like the idea of a new package type, at least in theory. The challenge is thinking through how a package would approach that. How would they adopt that w/rt servicing existing users. We need to thread the needle on that one. The compatibility constraints are pretty significant:. These are the ideal requirements for a package that wants to participate:
If we cannot satisfy those requirements, it is a tough sell. |
They are very noisy and not particularly useful.
https://www.nuget.org/packages?q=runtime.
At the same time, we want to ensure that we have good transparency for users.
What to do? Should we unlist these packages or keep them as-is?
I'll give you some context. The following is from a mail I sent today (to another party) on the same topic, which led to this question.
We started shipping .NET Core in 2016. You can think of the source code (at least structurally) as having remained constant since then but that we've tried a variety of approaches to building and publishing that source as binaries. All of those approaches are on display in NuGet.org. Package managers save everything to ensure continuity for consumers. That's a good thing, but it also can create a bit of a mess if there are multiple generations of technical schemes at play.
We ship the following distributions of of the .NET platform (and related packages):
runtime
packages (aka "runtime packs")I'll briefly describe these. The primary binary distribution of the runtime and sdk is available at https://dotnet.microsoft.com/download/dotnet. This is similar to downloading node.js or OpenJDK. The only key difference is that .NET SDK includes much more in the box than the other two examples. That's not a flex, but just being objective. In fact, everything for JavaScript devs is in npm except the npm tool and node.js runtime/environment. All good.
We have regular packages. These are just like NPM or Maven packages. EntityFrameworkCore is a perfect example: https://www.nuget.org/packages/Microsoft.EntityFrameworkCore.
You can even track that package back to source control. Check it out: https://nuget.info/packages/Microsoft.EntityFrameworkCore/7.0.0-preview.5.22302.2
That's this link: dotnet/efcore@01603c6
That means that the package was built from exactly that commit. There are ways to fake that out, but we don't do that. We ship that commit.
Note: I wish the commit in NPE was a link!
Let's get to runtime packs. This is where things get more interesting.
We had a LOT of runtime packages back when we first started. You can see a bunch of them at https://www.nuget.org/packages?q=runtime.. Most of those are abandoned now. You can see that in two ways: the last push was ages ago, and they have wonky version numbers (a lot are 4.x and we never shipped a .NET Core 4.x).
We should probably deprecate and/or unlist those packages. They are pure noise.
We do have relevant current patterns for these runtime packs. They provide the .NET implementation (in broad brushstrokes) for a given environment (like Linux x64).
https://www.nuget.org/packages?q=Microsoft.NETCoreApp.Runtime
https://www.nuget.org/packages?q=Microsoft.AspNetCore.App.Runtime
Those are the same except one is for the base runtime and the other is the web server, one layer up.
They are the same build of the product as is it at our download page, shared earlier.
The first is from: https://github.com/dotnet/runtime
The second is from: https://github.com/dotnet/aspnetcore
To make it more confusing, each of those repos builds their primary runtime deliverable, plus a bunch of associated packages.
In terms of scenarios, you download and install the product from the Microsoft download page when you want to have a globally installed product and develop or install multiple apps. We call this scenario "framework-dependent" since your app is dependent on a globally installed runtime/framework.
Some developers want to deploy the runtime with their app. We call that scenario self-contained. This is the scenario where those two categories of runtime packs are used. When you build your app, one or more of those runtime packages are downloaded and copied into your app. The local runtime on your machine is not used for that purpose (to copy into your app
bin
folder to make it self-contained). It's most obvious when you are on Windows x64 and wanting to build a self-contained app that will run on macOS Arm64, for example. You won't have that runtime on your machine, so it needs to be downloaded.We also have a smaller set of runtime packs that are dependency of "regular packages".
For example, System.IO.Ports has a direct dependency on runtime.native.System.IO.Ports.
You can see this on the dependencies tab at https://www.nuget.org/packages/System.IO.Ports/7.0.0-preview.5.22301.12#dependencies-body-tab
The clue with all of these packs as being supported is a recent push or a recent version number, like 6.x or 7.x.
The text was updated successfully, but these errors were encountered: