Spurious "provides" section

[ribasushi]

The release page of DBIC shows DBIx::Class::Optional::Dependencies as a lone provides. There is nothing mentioning provides in META, and the module itself is a regular .pm/.pod split just like many others. Yet DBIx::Class::Optional::Dependencies is the only one displayed incorrectly.

This is reminiscent of https://github.com/CPAN-API/metacpan-web/issues/724 but the failure mode is different.

[haarg]

What metacpan shows as "Provides" has little to do with CPAN::Meta::Spec's provides. Is that the failure you are concerned about, or are you more concerned with the UI being bad or misleading?

[ribasushi]

I am concerned with the latter. The UI singles out the module as if there is something special about it.

I mentioned META provides as part of "I looked there too" pre-diagnostic.

[nwellnhof]

You can hide the .pm file from the Provides section on MetaCPAN by adding it to no_index. That said, I also find it irritating that modules with external .pod files are listed a second time in the Provides section. I think the logic should be like:

• .pm with internal POD and external .pod: List module under "Modules", linking to .pm POD. List .pod under "Documentation".
• .pm with only external .pod: List module under "Modules", linking to .pod.
• .pm with only internal POD: List module under "Modules", linking to .pm POD.
• .pm with no POD at all: List module under "Provides", linking to .pm source.

Except for the second case, this should already match current MetaCPAN behavior.

[nwellnhof]

And after the change described above, the "Provides" section could be renamed to "Undocumented Modules" which would also fix #1152.

[oalders]

Closing as the latest release does not show a provides section at all.

[nwellnhof]

This might be fixed for DBIx::Class, but my CommonMark distro still has the same issue: https://metacpan.org/release/CommonMark

[oalders]

Ok, thanks. Re-opening.