-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Handle RID asset selection in SDK instead of NuGet #10025
Comments
Why is this necessary?
You mean"runtime packs", right? Thinking about the open questions, it seems easier to leave RuntimeIdentifiers alone for back-compat and have a different property to specify runtime packs. |
If we do this, we wouldn't need NuGet/Home#7351 from NuGet |
Does this mean that NuGet will restore the assets for all RIDs regardless of whether they're needed or not? Seems like it could massively increase the initial restore time when using packages with large native assets. |
@mhutch It means we wouldn't support RID-specific package dependencies. For .NET Core, the RID-specific dependencies would come from runtime packs, and only runtime packs necessary would be downloaded. We scanned the packages on NuGet.org and found that there weren't any current versions of third-party packages that used RID-specific package dependencies. |
Does that mean proposals like NuGet/Home#3114 won't be possible in the future? |
It depends how "anchor packages" would be discovered. It seems that the expectation is that users would reference them explicitly from my skimming of that proposal. If so, that could still work. |
It seems a shame to remove that capability just when it's on the horizon for platforms other than netcore. It would be super useful for things like SkiaSharp. |
I don't think we can remove the capability so much as not use it in some scenarios Even if .NET Core packages were truly the only thing that used this, we still need to handle .NET Core <3.0. I'm beginning to think that we should not do this feature and favor NuGet/Home#7351. It removes nothing and just adds another way to specify runtime.json. There are other ways to we can achieve some of the things this would solve such as putting RID-specific assets in separate RID-specific assets files. I suspect going after these things will be moved out past .NET Core 3.0. |
…es corefx dependencies (#1021)
@dsplaisted I wonder if this is the case simply because there isn't currently any reasonable user story for deploying RID-specific package dependencies in third-party packages? It doesn't seem a fair assessment to judge community interest based on whether they can hack their way through undocumented features which can only really be used with insider knowledge of current framework architecture. To be fair on this, you would have to analyse whether the community has a recurrent need for this feature. I would suggest searching nuget.org for keywords like "runtime", "native" or "linux" and you can easily find several high-profile packages which are trying to deploy RID-specific assets using a variety of different hacks. And even then, these are only the success stories. As cross-platform usage of .NET increases, the need to solve this properly will only increase with time. You could probably also trace this by looking at activity in issue trackers mentioning this problem in one form or the other over the last 2 years. |
@glopesdev Yes, I pretty much agree with you. The main point of saying that there weren't any third party packages using RID-specific dependencies was that we could remove the existing functionality without much impact, since no one was using it. It would also be nice to design a new mechanism for RID-specific package dependencies that was more usable and less technically complex. However, it looks like for now these ideas remain on the backlog. |
Proposal
Benefits
Open questions
The text was updated successfully, but these errors were encountered: