Split library and package Readme#78888
Conversation
|
Tagging subscribers to this area: @dotnet/area-extensions-configuration Issue DetailsI've initially submitted library and package Readmes as single file for Microsoft.Extension.Configuration libraries, but maintainers raised issue that this exposes unneeded information on NuGet gallery: #59630 (comment) So the new convention is:
|
|
Tagging subscribers to this area: @dotnet/area-meta Issue DetailsI've initially submitted library and package Readmes as single file for Microsoft.Extension.Configuration libraries, but maintainers raised issue that this exposes unneeded information on NuGet gallery: #59630 (comment) So the new convention is:
|
|
Tagging subscribers to this area: @dotnet/area-extensions-configuration Issue DetailsI've initially submitted library and package Readmes as single file for Microsoft.Extension.Configuration libraries, but maintainers raised issue that this exposes unneeded information on NuGet gallery: #59630 (comment) So the new convention is:
|
|
Tagging subscribers to this area: @dotnet/area-meta Issue DetailsI've initially submitted library and package Readmes as single file for Microsoft.Extension.Configuration libraries, but maintainers raised issue that this exposes unneeded information on NuGet gallery: #59630 (comment) So the new convention is:
|
|
@MSDN-WhiteKnight I hope it's OK that I pushed to your branch. I made the following refinements (three commits):
|
Does NuGet gallery look for PACKAGE.md? Or do we need to rename it to README.md as part of packing? |
NuGet uses file specified by PackageReadmeFile property. This property is now globally set in packaging.targets to PACKAGE.md so yes, it will be recognized. |
|
|
||
| <!-- Add a package README file from. --> | ||
| <ItemGroup Condition="'$(PackageReadmeFile)' != ''"> | ||
| <None Include="$(PackageReadmeFile)" Pack="true" PackagePath="\" /> |
There was a problem hiding this comment.
| <None Include="$(PackageReadmeFile)" Pack="true" PackagePath="\" /> | |
| <None Include="$(PackageReadmeFile)" Pack="true" PackagePath="README.md" /> |
You want the file to be named README.md, right?
There was a problem hiding this comment.
We don't have to specify name README.md, NuGet will recognize any name set by PackageReadmeFile property. Also PackagePath seems to be a path without name, it is used like that in docs: https://learn.microsoft.com/en-us/nuget/reference/msbuild-targets#packagereadmefile
| <!-- Don't include target platform specific dependencies, since we use the target platform to represent RIDs instead --> | ||
| <SuppressDependenciesWhenPacking Condition="'$(TargetPlatformIdentifier)' != ''">true</SuppressDependenciesWhenPacking> | ||
| <PackageDesignerMarkerFile>$(MSBuildThisFileDirectory)useSharedDesignerContext.txt</PackageDesignerMarkerFile> | ||
| <PackageReadmeFile Condition="'$(PackageReadmeFile)' == '' and Exists('PACKAGE.md')">PACKAGE.md</PackageReadmeFile> |
There was a problem hiding this comment.
Maybe the file name could be PACKAGE_README.md? PACKAGE.md doesn't really describe exactly what the file is.
There was a problem hiding this comment.
When it comes to NuGet Gallery, the PACKAGE.md file is automatically respected and displayed as the package's nuspec encodes it. Personally, I'm fine with the PACKAGE.md name and I don't think it's common that a dev crack opens a nuget package in order to understand how to use it.
There was a problem hiding this comment.
It's more about readability/understandability of the files in the repo.
There was a problem hiding this comment.
Other options include:
PackageReadme.md- The file under a
docsfolder, and still name itREADME.md. e.g.src/docs/README.md - Since the files are split already - one is in the root of the library, and one is under
src- they could both be namedREADME.md.
There was a problem hiding this comment.
The PACKAGE.md choice was based on this suggestion: #59630 (comment) I don't think this name needs to be long as there's not a lot of .md files in folder to disambiguate between them. So personally i'd prefer either README.md or PACKAGE.md.
There was a problem hiding this comment.
Being able to distinguish between a package documentation file and a repo specific contribution guidance seems valuable to me. We unintentionally started shipping the contribution guidance files to customers and this PR fixes that: #59630 (comment).
| <IsPackable>true</IsPackable> | ||
| <!-- This library has been annotated to be AOT safe --> | ||
| <EnableAOTAnalyzer>true</EnableAOTAnalyzer> | ||
| <IsPackable>true</IsPackable> |
There was a problem hiding this comment.
Why is this moved/changed? Seems unnecessary.
There was a problem hiding this comment.
It was moved to group packaging properties together.
|
@MSDN-WhiteKnight can you please update https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/libraries-packaging.md and add a section that describes the new conventions (including mentioning/explaining that the file is automatically included in the package if conventions are followed)? |
I've added a section about Package readme, and also edited PackageDescription guidelines to remove the list of entry-point types (it is now obsolete as including it in readme does it better). Should i also explain what is library readme and how it's different from package readme? In libraries-packaging.md, or in some other higher-level document? |
Thanks a lot. Regarding libraries README files, those are already documented in the src/libraries/README.md file: https://github.com/dotnet/runtime/blob/main/src/libraries/README.md |
I've initially submitted library and package Readmes as single file for Microsoft.Extension.Configuration libraries, but maintainers raised issue that this exposes unneeded information on NuGet gallery: #59630 (comment)
So the new convention is:
/cc @jeffhandley @ViktorHofer
Related to: #59630, #77733