feat: link to nuget dependencies

[lonix1]

Add links to dependencies and their versions, as done in nuget site. Makes it easier to use.

cc @KN4CK3R

[KN4CK3R]

Not every dependecy is hosted on nuget.org

[lonix1]

Good point!

Do you think there's a way to detect that?

[silverwind]

Looking at a nuspec file, dependencies do not list their URL there, so I'm afraid it's not possible to know where a package is hosted. Question is thought if we could accept potentially being wrong with these URLs.

<dependency id="Microsoft.CSharp" version="4.3.0" exclude="Build,Analyzers" />

[silverwind]

On the other hand, how do private dependencies look in the nuspec file? I assume there must be some kind of URL so the package is able to be retrieved. If that is so, you can distinguish private packages.

[lonix1]

I suspect you are right there is no way to extract the URL (but I don't know for sure!). So I can delete this PR if you agree.

However, if that is the case, how does nuget do it? Each package on nuget links to other packages. So they just assume everything is on nuget? I guess when you are as big as Microsoft you can make those assumptions and get away with it! :-)

[silverwind]

So they just assume everything is on nuget

I think that must be the case, yes. So until the package metadata gains a field to specify registry, there can only be guessing.

I still think a bad guess is better than no link, so I can accept this nonetheless.

[lafriks]

Maybe we can check first if it is local dependency in this instance and link to it and only use nuget.org as fallback?

[silverwind]

Maybe we can check first if it is local dependency in this instance and link to it and only use nuget.org as fallback?

Great idea. That would be ideal, yes.

[lonix1]

Maybe we can check first if it is local dependency in this instance and link to it and only use nuget.org as fallback?

So that I understand, let's say you have package MyOrg.Server with dependencies:

• Microsoft.Foo
• Microsoft.Bar
• ThirdParty.Foo
• MyOrg.Utils
• MyOrg.Common

Then MyOrg.* would be found in the gitea instance and so links would be created as I noted above. But the rest would not be found, so one would create links to nuget instead?

(If that's the case, I'm not a go dev, so I don't know how to improve this PR... sorry!)

[silverwind]

Yes, correct. I estimate that the majority of use cases of private packages are with a single local registry with fallback to an official one. Multiple private registries could only be supported with additional metadata in the package's dependencies.

[silverwind]

@KN4CK3R I think such a linkification would be nice for all package registries. Check if dependency exists in local registry, link there if it exists, otherwise link to official registry.

[wxiaoguang]

I agree with some options above: such link for all packages is not ideal. Especially it might confuse and scare users who are using private packages and care about privacy a lot.

Maybe a better (but still not ideal) solution is to add a separate link "Search it in NuGet Gallery"

[silverwind]

A link won't hurt anyone, I suppose.

We could decorate it with link-external to reinforce that it's external.