Modules are being found, and indexed in search, in a distribution's local/ directory

[karenetheridge]

https://metacpan.org/release/HTTP-Thin-UserAgent (version 0.008) is displaying documentation for, and also indexing as the first result in search, many modules that are not rightfully "provided" in the documentation.

(Does metacpan respect the meta 'provides' field, when present? that would help in general, although not in this case since that field wasn't included in META.*.)

[oalders]

On a sort of related note, what it would it take to get Dist::Zilla to ignore local/ by default? That would prevent a lot of these cases from happening in the first place.

[rwstauner]

rats, i thought we were doing that (no_index-ing local)
b/c I recall when pause added that.

yes, we do currently respect provides.

thanks for reporting that.

[tsibley]

Yes, it respects the provides field if present: https://github.com/CPAN-API/cpan-api/blob/master/lib/MetaCPAN/Script/Release.pm#L328-L417

[karenetheridge]

Including [MetaJSON] and [MetaProvides::Package] in dist.ini should solve it (given my assumption that metacpan already respects this data), because it is more sensible about where to look for modules.

Also, switching from [GatherDir] to [Git::GatherDir] would omit build cruft from being included in the final dist.

[karenetheridge]

In general, would it make sense to only consider modules for search-indexing that were included in lib/ (and I suppose the top level directory, for backcompat - e.g. URI does this)?

[rwstauner]

I'd love to do that, but i don't think it's sufficiently
backward-compatible, sadly.

[oalders]

IIRC this approach would probably break some dists.

[oalders]

Let's start with blacklisting local. @rose this also is based on your earlier work.