David Golden wrote:
> On Nov 18, 2007 9:27 PM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
>> David Golden wrote:
>>> So, yes, it was a crappy design decision/hack, but now we're stuck with it.
>> No, we should not wedge ourselves into a corner like this. Preventing a
>> better way of doing it from going into a protocol because there's a handful
>> of
>> code that uses the old way is doomed to render protocol improvements
>> impossible. META.yml is versioned just to handle this sort of thing.
>
> I think you're taking my quote out of context. My broader point was
> that adding a new key doesn't take away the need to support the hack.
> And adding a new key creates work. And, as you put it in your "5.5
> not supported" email, this is volunteer work, not paid.
I don't think anyone thinks it won't involve work.
> I'm not opposed to forward progress, but I'd like a more thoughtful
> analysis of the use case.
Ok.
>> overboard on the backwards compatibility police to protect those. We're not
>> even talking about removing "requires: perl", just adding a better way.
>
> As long as we're talking about better ways -- let's consider how to
> reconcile this idea (and configure_requires) with dynamic_config
> defaulting to 1 if omitted. E.g. CPAN.pm ignores META.yml
> requirements if dynamic_config is 1 and only gets requirements after
> Makefile.PL or Build.PL runs. Oh, wait, except for configure_requires
> -- because that's needed before we can run those. So in one case
> dynamic config is ignored instead of honored.
>
> Presumably perl_version would not be subject to dynamic_config -- or should
> it?
Ideally there would be a way to say "configuration requires perl version X.Y",
just like we can do with modules. But rather than having a pile of
"perl_requires" and "perl_configure_requires" and "perl_recommends" it would
be nice if we had a way to say "I (require|recommend|configure_requires|...)
version X.Y of Z external program" because eventually we're going to want this
for C compilers and databases and the like. I talked about this the last time
this came up.
The trick is how do we figure out the version, or even a unified name, of any
given external utility? The answer, as far as the META.yml approach is
concerned is "let the consumers figure it out". Really. We just need to
provide the semantics. So what would those semantics be?
That's the complete solution. The alternative small solution, someone
suggested, is we just ship a "perl.pm" which sets it's $VERSION to be the
current Perl version. That's the hack to make "requires: perl" "just work"
without any special casing on the part of the consumer. I think it piles a
hack on top of a hack.
--
<Schwern> What we learned was if you get confused, grab someone and swing
them around a few times
-- Life's lessons from square dancing
