# from David Golden
# on Sunday 06 September 2009 21:53:
>> 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.
Why not? If it's properly specified and pod-renderable, things like the
distribution status, author, bugtracker, repository, tags, blahblah,
can be human-readable and appear in perldoc while also being
machine-extractable.
That is, I'm quite happy with Getopt::AsDocumented, and it
(suboptimally) reads the caller's own pod at runtime (VS metadata,
which is often not needed at compile/run time at all.) I can write the
documentation and declaration at the same time.
It seems that anything which isn't referenced by use() would ultimately
cause less trouble by being some bit of text rather than compile-able
code.
And whatever is referenced on the installed machine need not be the same
file that M::B parses when it builds a dist -- once the info is in
META.yml you're done parsing. (Picture say, keeping MYMETA.yml on the
installed tree plus a scheme for querying that.)
>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;
Well, what about "author", "tags", "repository", etc? Where the version
number is a necessary thing and reduces boilerplate code, the status is
an unnecessary thing which adds boilerplate code.
The '_' in your VERSION vanishes within the runtime because of the
necessary eval(). The status and some way to query it is not a
necessary part of the package -- plus all of this is really dist-level
stuff and you're opening yourself to multiple conflicting status values
per .pm file.
>...
>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.
I think you're going a bit knee-jerk on the maintenance concerns of the
trigger mechanism. The author features of M::B don't need to be so
set-in-stone because the author has control over which M::B they're
running and responsibility for doing what it expects. That's not to
say that I want to build something hugely complicated and then rip it
out from under everyone on the next version, but the "# ALPHA" parse
feature is small and special enough that it shouldn't be a big deal.
And as for the rest of the toolchain: if we implemented a pod-parsing
META declaration scheme, that would be a M:B feature which M::I could
choose to replicate or not. There is no need to hold back M::B just to
make it easier for users to switch tools. The produced data should
adhere to the META spec, but how the user declares that data is up to
their tool.
--Eric
--
software: a hypothetical exercise which happens to compile.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
