> > 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"
I for one think "recommends" is a stupid idea, since it's completely ambiguous and doesn't add anything of interest to the toolchain (asking the user is the worst thing to do), but I digress. 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? I've discussed this once or twice with Audrey, and more recently with an RDF expert friend of mine. The starting point would seem to be some sort of universal identifier for software projects, that had a structure involving the toolchain needed, and the package identifier relevant to that toolchain. So our stuff is cpan:Foo::Bar, etc. But that's a much bigger problem, and bigger even than META.yml, more like some sort of larger semantic RDF metadata we'd generate from META.yml but would need buy-in from 3-4 other language communities first. In the mean time, perl_requires specifically for META.yml (which is Perl-only) is reasonable.
