Revert "Add nuget package provider"

[stevapple]

Reverts #5486

NuGet is being excessively used to support C# and .NET on multiple platforms, but SwiftPM can hardly consume its package in practice. NuGet works in a totally different way from the other package managers we supported before.

• NuGet cannot install packages globally, when you run nuget install you're actually downloading the packages into current working directory. The behavior diverges with the SwiftPM warning.
• NuGet packages contain only runtime resources, not development libraries. There're no header files and import libraries that SwiftPM can make use of. Supporting NuGet is non-sense.

Additionally, even if NuGet is said to support "native packages", these packages are not always vendored by trustable sources and only make up a small set of the packages. Microsoft has already introduced Vcpkg to handle C/C++ libraries, and its products are directly usable for SwiftPM. (Although @neonichu suggested that such support had better be implemented by a plugin, it seems impossible for now because binary and headers cannot be consumed.)

I'm going to close #4369 as not planned too.

@compnerd If your purpose is to pass the test suite on Windows, I would suggest adding a dummy provider for all platforms, instead of any exact one.

[tomerd]

cc @compnerd

[compnerd]

The purpose is not to just pass the test suite. Nuget supports C/C++ "excessively". It is the preferred mechanism for supporting integration with builds. This should be retained.

[stevapple]

@compnerd If you think NuGet is worth being supported, could you answer these questions:

1. How many NuGet packages can SwiftPM consume with little effort?
2. How many NuGet packages is possible for SwiftPM to consume?
3. How many consumable NuGet packages is still actively maintained?
4. How do you plan to deal with its inability to install everything in a single place?
5. From which point do you think NuGet can provide similar experience to HomeBrew, Apt and YUM?

[compnerd]

I don't have the numbers for nuget, but you are free to browse nuget.org for the ~300k packages. I'm working through the problems of static linking (waiting on Apple for some stuff) that is needed to make further progress on that. Nuget is already used for integration of different systems, and in fact is how we consume the VS Installer SDK for the installer. This is not meant to be an exact replacement for brew/apt/yum - because that is not helpful on Windows. It does however provide a way to get the packages and link them into the Swift package that is being built, which makes it equivalent and better because the installation problem is not a problem - you will have to distribute dependencies on Windows because that is the only reasonable way to deal with DLL hell.

[stevapple]

You said that there’re ~300k packages on nuget.org, but the reality is there’s only 2,898 "native" packages, only ~960 of which have been updated in the past year. Can it really be described as excessively used in C++ development?

Even worse, there’s a bunch of redistribution-only or header-only packages among those native ones, which makes no sense to SwiftPM as a “target” — these can only be used as resources. Some of the packages (eg. microsoft.windows.cppwinrt) contains only MSBuild rules instead of headers, and I don’t think it can be supported in SwiftPM in the near future.

All in all, I believe NuGet makes little sense to SwiftPM at the time. The .nuget() provider has no actual capability yet, and even its message is false. I’m all on introducing a test-only dummy provider, but please don’t let this into any release.