Add support for the `repository` property in .nuspec
Support for a repository property in NuGet .nuspec files was added a while back, with the idea being that this would make tracking both the project's website (using the existing projectUrl property) and the package's source code (using the new repository property) clearer.
Chocolatey already had the packageSourceUrl property to achieve this.
However, some package repositories, such as GitHub Packages, will now not allow packages to be uploaded without the repository property being set in the .nuspec file:
WARNING: No destination repository detected. Ensure the source project has a 'RepositoryUrl' property defined. If you're using a nuspec file, ensure that it has a repository element with the required 'type' and 'url' attributes.
I believe this leaves 4 options:
- Add support in
choco packfor therepositoryproperty alongside the existingpackageSourceUrlproperty.
- Backwards-compatible, and allows GitHub Packages to be used as an package repository.
- Will lead to duplicated properties if used (i.e. the
repositoryproperty and thepackageSourceUrlproperty would be set to the same value).
- Automatically transform the existing
packageSourceUrlproperty into therepositoryproperty inchoco pack's generated.nuspec.
- Not backwards-compatible, will cause existing tools that depend on
packageSourceUrlto break. - Cleaner than option 1 - no duplicate properties.
- Require the
repositoryproperty to be used in.nuspecfiles rather than thepackageSourceUrlproperty.
- Not backwards-compatible, publishers will have to update their
.nuspecfiles. - Existing tools that depend on
packageSourceUrlwill have to check for therepositoryproperty first, then fallback to using thepackageSourceUrl.
- Do nothing
- Prevents GitHub Packages and possibly other package repositories that use the current
.nuspecspecification from being used. - Divergence between NuGet
.nuspecfiles and Chocolatey.nuspecfiles. Whilst they are different tools, given that Chocolatey leverages NuGet package repositories, I think as much compatibility as possible should be the goal?
Happy to contribute, but I think this requires input from others before making PRs and changes.
This feels like it has overlap in https://github.com/chocolatey/choco/issues/508, maybe even depends on that aspect. Like GitHub repositories only support NuGet v3, not NuGet v2, which Chocolatey would need at this time.