On Sep 22, 2007, at 3:54 PM, David Golden wrote:
On 9/22/07, Ken Williams <[EMAIL PROTECTED]> wrote:
My understanding is that "no_index" is only useful when "provides"
isn't there and an indexer has to guess what you provide. When
"provides" is there, it should be exhaustive. Note that the spec
says "indexers will usually trust the C<provides> field if it's
present." That's just a recommendation from me to the owners of the
indexers, but I think it's one they follow.
So in Schwern's case, "provides" should indeed win, and furthermore
you should be able to just remove "no_index" altogether.
If you're saying that if "provides" is there, indexers should *only*
index those and not do any other searching?
Yeah, more or less. I don't control the indexers, though, so of
course they can do whatever they want. And of course each indexer
can have a different purpose from the others, so there's no one-size-
fits-all declaration for them.
For instance, PAUSE indexes are intended for the use case I
mentioned: if you want to get Foo::Bar, install version X of
distribution Foo. But search.cpan.org probably wants to be more
liberal, so that if you want to find all places where a Foo::Bar
module is created in CPAN, it'll show it to you (subject to whatever
Graham finds prudent).
Time permitting, I suggest that the META.yml spec be updated with some
tighter "must", "should", "shouldn't" kind of language to make these
kinds of cases more explicit.
I think the META spec shouldn't add that kind of language, actually,
because as I mentioned above, various consumers of the metadata can
be doing very different things with it. I think the spec needs to be
more explicit about what it *means* to put a certain value in a
certain field, though, so that consumers of META.yml can understand
exactly what the author is asserting about their distribution in it.
I agree that at the moment those consumers only have a vague idea
about what "no_index" and "provides" really mean.
-Ken
