On Tue, Jan 27, 2009 at 8:00 PM, Adam Kennedy <[email protected]>wrote:
> I know we kind of agreed on METALOCAL.yml at the last QA hackathon, > but I have to say I've come around to the shorted (and 8.3-compatible > fwiw) MYMETA.yml. > > It's also easier to type. > MYMETA.yml++ > > I'm gunna do a first implementation of my_meta; as a specific command > in M:I's next release, to give us some stuff to play with. > Please, please lets try to avoid over-engineering this. (ant? embedded code? ick!) Let's start relatively simple and see where it goes. My initial thinking: * The "spec" for MYMETA.yml should be identical to META.yml except that MYMETA.yml *must* set dynamic_config: 0 * if META.yml sets dynamic_config: 0, then MYMETA.yml should just be a copy of META.yml * Any configuration-time changes to requires, build_requires etc. just get put in the appropriate sections * Let's either not include any %Config stuff or else let's include the whole thing. I favor the former to start. Anything that is local has %Config already and anything that collects MYMETA.yml for analysis can collect %Config at that time. If we think it has to have %Config stuff like perl version and archname, let's include the whole %Config hash and not have to go back and add things later that turn out to be necessary. (Future proofing) * We should hash this out on a wiki somewhere -- I'd prefer to quickly hammer out a draft of how it should work and then have tools implement against an agreed draft rather than have one tool trailblaze and then everything else follow the initial version plus any idiosyncracies introduced. (We can vote on a final spec at the QA Hackathon if necessary :-) I'll commit to adding MYMETA.yml support to CPAN.pm once a spec is agreed upon -- using that for requirements if it exists instead of the normal Makefile parsing or whatever. And if I'm asked nicely, I might just go add "recommends_install_policy" as a new CPAN option along the lines of "build_requires_install_policy". -- David
