On Mon, Sep 7, 2009 at 2:15 AM, Eric Wilhelm<enoba...@gmail.com> 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
