Re: declaring meta info in a .pm

On Mon, Sep 7, 2009 at 2:15 AM, Eric Wilhelm<[email protected]> wrote:
>>> 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.

I thought you were implying a Pod section "=begin meta" or something.
I'd take comments over that any day.  A downside of Pod is that it
isn't guaranteed to exist and this starts imposing conditions on
personal development styles, plus of course, the usual natural
language processing problems.

> (Picture say, keeping MYMETA.yml on the
> installed tree plus a scheme for querying that.)

I've already added that to the CPAN Meta Spec proposal page, as it has
benefits that go way beyond knowing release status of installed
modules.

>>    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.

That's why I haven't implemented "package Foo 1.23 stable" nor the
"package Foo :ver(1.23) :auth(JDOE) :rel(stable)" syntax that was
suggested.   These are all orthogonal issues to version number
declaration, which *is* a package level thing, though it cascades to
modules and distributions.

C.f. http://www.dagolden.com/index.php/308/packages-modules-and-distributions/

> I think you're going a bit knee-jerk on the maintenance concerns of the
> trigger mechanism.

Heh.  How many toolchain modules am I working on now?  Excuse the
knee-jerk reaction.  :-)

In seriousness -- I'm running the process to revise the Meta spec.
I'm confident that will lead to consensus around dealing with release
status.  I don't want to front-run that process.

Also, I'm encouraging other toolchain maintainers to try to work in
consensus.  I'd rather not see things like PERL5_CPANPLUS_IS_RUNNING
or M::I's "test_requires" again*.  If I'm going to ask them to work on
a maintainer consensus basis, I need to do the same for M::B
maintainers (because I am one).

* Digression on test_requires: M::I offers a 'test_requires' keyword
"for the future", even though (a) there's no such thing in META.yml,
(b) it puts things in build_requires in META.yml and (c) during
install, it's all squashed into PREREQ_PM anyway.  I periodically have
to explain this to people on #toolchain as well as tell them that, no,
M::B is not going to add that "feature" until it's in the spec.  It's
an attempt to influence the spec development process by creating a
user-base.  Even though I'm fine with the concept of 'test_requires',
I don't like that as a development process, particularly when the
implementation is not what it claims to be.

> 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.

Can you help me understand the urgency? Why not wait a few months?
Yes, underscores suck.  Why do we need "# ALPHA" right now when you
say that it's OK to rip it out again in a future version?  Is there a
particular need you're trying to solve, or it general impatience to
see some sort of progress on the issue?

> The produced data should
> adhere to the META spec, but how the user declares that data is up to
> their tool.

I think I agree on that point, though I still prefer avoiding tool
lock-in and would like to see similar semantics in any tool.  (Does
"ALPHA" mean "unstable"?)   Perhaps my knee-jerk reaction is to seeing
new hacks on the $VERSION line to replace the old hacks.

-- David