RFC: Move away from NuGet.org Packages Index #RFC2021-01

[iJungleboy]

We're one of the first people to actually create an Oqtane module and put it on NuGet: https://www.nuget.org/packages/ToSic.Imageflow.Oqtane/

From this limited experience I have a feeling that NuGet.org (the site) is not a good idea for distributing modules. That's what I would like to discuss here.

Note: I'll maintain the following list if responses include additional aspects for this summary

Some Requirements for Module Distribution

1. Metadata should allow the Oqtane to only show modules which apply to it. So It needs rich metadata like versions supported, descriptions, maybe an icon etc. I think NuGet doesn't support this - at least not in a way that the rich metadata can be retrieved as a list.
2. Filtering by this Metadata - should happen on the packages-server (in this case nuget). I don't think we can filter against rich metadata (if this could even be supplied)
3. Ability to lock out malicious packages - since anybody can add packages or re-add them again and again with new names.

Some Nice-To-Haves

1. Even more metadata with pre-defined tags to categorize by type
2. Ability to group by creator
3. License information

Clashes with NuGet.org Core Purpose

1. In certain cases the Oqtane installer package must be different from the VisualStudio package. In some cases it needs multiple different installers (image Resizer incl. very large additional files which are linux/windows/mac specific ) it can lead to the same module being listed 2-5 times in NuGet, making it error prone that people will pick the wrong one in VS or during installation.

Recomendation

latest update to the recommendation: 2021-04-24

I believe that we need a custom index which is under our control. Ideally it would allow people to add 2-3 types of sources

1. Uploads
2. github release references

The Index-server would then either automatically get metadata based on this - or the user that adds it must do it in a UI (more reliable). Minimal stewardship would ensure that there is a bit of control. And API would then allow Oqtane installations to query the index in an IFrame (specifying the system requirements) and the IFrame would then provide a UI which can be updated as needed without having to upgrade the Oqtane itself.

[ADefWebserver]

As the 'other person' who has created Oqtane modules and posted at least one on NuGet :) :) These are valid points, but, I feel it is 'too late' because this would be a massive breaking change. Thanks!

[sbwalker]

I do not agree with the title of this RFC - but I do agree with the concept. Oqtane does need its own "registry service" where package authors can identify their packages and provide additional metadata as described above. This registry service should be independent from Nuget.org and not dependent on the discovery services provided by Nuget.org. Rather than interacting with Nuget directly to obtain information about packages, the framework should interact with this registry service. I have already started creating the admin UI for this service a few months ago, as I would expect that it should live on oqtane.org ( ie. as the official package registry for Oqtane ). Note that the registry can still point to Nuget.org as the download source for the actual Nuget packages as Nuget.org provides a robust infrastructure for the distribution and consumption of Nuget packages.

[iJungleboy]

I updated the title a bit - feel free to adjust as needed :).

[ADefWebserver]

@iJungleboy - Perhaps we are going to make an "Additional Module Distribution Method" ?