Provide repo link as part of nuget package

[thompson-tomo]

Description

I would like the repository url to be set on the nuget package which will make it visible in nuget and other tools.

Background

No response

Specification

No response

[FlorianRappl]

We have the symbols package published which leads to the sources in the repository. Along this the package has the project URL, which contains a reference to the repository.

Not sure what that should help. Any specific use case that cannot be covered otherwise?

[thompson-tomo]

The use case is if the dedicated repository property is used a direct link is published on the nuget listing. At the same time I generate an SBOM of all my dependencies which includes the repository url property etc.

[reduckted]

Not sure what that should help. Any specific use case that cannot be covered otherwise?

I have some automation that uses the repository URL to get the license file for the package. Without a repository URL in the NuGet package, the license file cannot be automatically found.

An alternative for me would be to include the LICENSE file in the NuGet package, but adding the repository URL to the NuGet package would be sufficient for my use case.

[FlorianRappl]

OK why do you need the license file from the repo? This does not make much sense as its not reliable. For example, if you download the package in version 1.0.0 you'd need to find the point in time of the repo where the package was published (maybe you get to this point via a tag, but even if a repository in question uses tags you might not know the naming convention / how the tag was named for the particular version). And even then it might not be reliable (there might be multiple packages coming from the repository, and the root / or any other path might not contain the LICENSE file used for the package).

NuGet has multiple fields for license - AngleSharp uses the license expression field (https://github.com/AngleSharp/AngleSharp/blob/devel/src/AngleSharp.nuspec#L8). If you find a particular expression (e.g., MIT in this case) you don't need the license file. It's a standardized license, meaning you can just refer to it via the expression (e.g., https://opensource.org/license/mit).

[reduckted]

For example, if you download the package in version 1.0.0 you'd need to find the point in time of the repo where the package was published

The nuspec file can specify the commit hash.
https://github.com/NuGet/NuGet.Client/blob/5502baa16a294bb1290b6fd2a135694ed2884a59/src/NuGet.Core/NuGet.Packaging/compiler/resources/nuspec.xsd#L85

If there's a repository element (like the one added in PR #1169), then dotnet pack includes the commit hash automatically.

It's a standardized license, meaning you can just refer to it via the expression (e.g., https://opensource.org/license/mit).

There's a difference between the template and the actual license in this repository.

The template has placeholders:

Copyright <YEAR> <COPYRIGHT HOLDER>

Permission is hereby granted, free of charge, to any person obtaining a copy of ...

whereas the license in this repository says:

The MIT License (MIT)

Copyright (c) 2013 - 2024 AngleSharp

Permission is hereby granted, free of charge, to any person obtaining a copy of...

[FlorianRappl]

Again, this way is not reliable. Not sure if you read my entire message - there is no way to identify what is the correct license file. You should get the license information from the package - not the repository; as you also consume the package - not the repository.

In any case - if there is a license attached to the NuGet package (via one of the metadata fields) it takes precedence. Your way can be a great fallback mechanism, but nothing more.

[reduckted]

there is no way to identify what is the correct license file.

It's often called LICENSE or something similar and is very easy to locate. Even GitHub can work out what the licence of a repository is using this technique.

I don't really understand the pushback to adding a single line to the nuspec file that is very common in just about every other NuGet package. There's no maintenance burden. There's already a pull request for it.

[FlorianRappl]

I don't really understand the pushback to adding a single line to the nuspec file that is very common in just about every other NuGet package. There's no maintenance burden. There's already a pull request for it.

Since you seem to be invested in AngleSharp (potentially using it) I wonder why you don't invest in it. You did not give a star, no sponsor support, no PR or contributions in any other form.

I think you confuse the use-case discussion that you have with the PR. There is no push back on the PR; and the issue is still open. It will be merged when the time is right - but until then there is no need. The package was fine beforehand and is still fine. The addition is neat and useful, but not crucial.

Regarding the discussion; you still fail to understand that just identifying a repo license is not the same as the package license; they might be different and therefore you will in general be in trouble - as I assume you do the license gathering for legal reasons. The package license always takes precedence (technically and legally) - if you disregard this you'll be in trouble.