On Sun, Sep 6, 2009 at 1:39 PM, Eric Wilhelm<enoba...@gmail.com> wrote:
>>> For reason #2, I'm reluctant to do it with e.g. a command-line
>>> option or Build.PL parameter. Some sort of artifact in the deployed
>>> .pm is very useful for debugging an installed module.
>>
>>I have mixed feeling about this. Until *Perl* has specific semantics
>>around this, I'm reluctant to add semantics in the form of comments,
>
> I think comments are going to be the least invasive/verbose mechanism.
> You want to use the pod?
>
> I would be very sad to see a runtime module requirement just to declare
> some rarely-used meta info. Ditto for requiring a new Perl.
POD? Hell, no.
But, for the sake of argument, let's say some bold, foolish programmer
implements an extended 'package' keyword for Perl, like so [1]:
package Foo 1.23;
And, following popular demand, at least based on #corehackers and
#toolchain, he implements a way of marking module release status, like
so:
package Foo 1.23 stable;
And lets assume that "stable" "testing" and "unstable" were the
allowed status flags to an enhanced package line. If such a patch
were added to core, clearly, M::B and EU::MM would need to be patched
accordingly.
As you say, that's fine for future Perls, but what about older ones?
I would argue that using comments as a backward compatible hack is OK,
but that stable/testing/unstable should be used instead of ALPHA.
That's a contrived case to be sure, but my point is that I'd like to
figure this out once and not have one semantic for M::B, one for
blead, another one for M::I, no semantic at all in EU::MM and so on.
It's all the same problem, so I'd like Oslo-style consensus, so if we
have to use ugly hacks, the whole toolchain is consistent with it.
E.g. The Olso consensus around listing "perl" in "requires" -- even
Schwern came around and joined the consensus to keep it [thank you,
Schwern!].
Give me consensus and I'll be the front ranks of implementers, but if
the idea is Module::Build blazing a trail, I'm violently opposed.
> As I said, I only need to do it one way once with a given M::B. If a
> better mechanism is developed, I'll use that the next time. (I know
> we're good at thinking of edge cases around here so I'll
> preemptively 'meh' all of those now.)
Rebuttals to your "meh": YAML for Meta, version.pm, PERL5_CPANPLUS_IS_RUNNING
There are a lot of dubious decisions that seemed like good ideas at
the time that we maintainers are living with. So "meh" to your "meh".
:-)
>>Should we bikeshed the issue to death?
>
> I don't mind if other people's problems also get solved. I do mind if
> my problem gets snowed under an architectural astronomy project. ;-)
Agreed. Bound the problem around how flag, capture and communicate
distribution status and let the rest of the meta issues go.
> Iff you extend it beyond the "# ALPHA" without developing something
> formal and reproducible, this is what you'll get.
(formal and reproducible)++
> If we're adding something to META.yml and can change mldistwatch to see
> that, we don't even need a specially-formatted tarball name.
Exactly.
My suggestion is:
* Define a 'release_status' field in the new CPAN Meta Spec that
clarifies the semantics of what a release status is, and whether there
are synonyms for various release levels. (E.g. alpha = unstable, beta
= testing, is there a 'release candidate' status, and so on)
* Have PAUSE start using the new field if it exists
Then, and only then, do we figure out if it should be a comment, or
just be set in Build.PL or whatever because we'll have thought through
the issues with other toolchain developers and can probably quickly
agree on a common approach.
-- David
[1] http://github.com/dagolden/perl/tree/package-name-version
