[Top] [All Lists]

Re: Perl 6 modules on CPAN

Subject: Re: Perl 6 modules on CPAN
From: Steffen Mueller
Date: Tue, 25 Aug 2009 10:52:15 +0200
Newsgroups: perl.cpan.workers

Hi Moritz, hi Andreas,

(Andreas J. Koenig) wrote:
On Mon, 24 Aug 2009 09:31:38 +0200, Moritz Lenz <[email protected]> said:
 >>> 2) The uploaded modules have a flag in their META.yml marking them as
 >>> Perl 6. The indexer ignores such modules, so that they don't appear in
 >>> modules/02packages.details.txt.gz or modules/  (in
 >>> order not to disrupt the work flow of anything that deals with Perl 5
 >>> modules

Years ago I tried to suggest a language tag for META.yml but it was
not appreciated then, so let's see what we have instead now.
There's a plan to get a META spec 2.0. CC'ing perl.cpan.workers.

When a module has a "provides" key in the META.yml which references an
empty hash then the indexing is disabled. The user gets a mail that
contains text like this:
This might be appropriate for immediate use. I see nothing else that
is ready to use without a code change.
This is at least a vehicle for making this work.

  > There are heuristics, yes. For example a 'use v6;' is a pretty sure
  > indication that something is Perl 6 code. I know the Padre developers
  > have some heuristics already implemented; if there is general consensus
  > that we need such a thing I'll look there for prior art.

Maybe you can persuade the perl6 authors to do some tiny bit of
homework in their distros so that we do not have to start with
heuristics again? I'd recommend working with heuristics only if some
better solutions have been tried and have failed.
Well, it was me who suggested heuristics, so let me clarify:
i) The only way to indicate that a distribution should not be indexed as a perl 5 distribution would be declarative. Probably through META.yml either via the provides hook (which seems like a workaround) or via an explicit flag. ii) As a safety net to prevent potential damage to the way perl 5 CPAN works, the indexer could refuse to index distributions that
=> look like they contain perl 6
=> and do not specify whether they are perl 5 or 6.

This way, the heuristics would only EVER kick in if a certain, simple flag was missing from META. This is the reason that the "provides" solution would be inadequate. A PAUSE rejection mail could prominently state that the rejection can be circumvented by explicitly adding some tentative "language: perl5" "language: perl6" or "languages:..." or whatever tag to META.yml. This way, false positives have very low impact.
I agree that heuristics directly affecting the index is bad. Heuristics
as a guard against a huge mess is good.
This being said, I'm not going to write the code but leave that to those
who need it. (Sorry, Moritz)

<Prev in Thread] Current Thread [Next in Thread>