"META.yml, but adapted to the platform" was indeed the original concensus.
There's not really any need for dynamic_config: 0 that I can see, since it means "Can META.yml be trusted". Even if it's not zero, it's still correct. All I plan to do is load META.yml into memory, then overwrite the requires/etc fields from the M:I code. And there's no reason for any %Config stuff correct, since the mere fact it exists is proof enough that it's localized and correct. Finally, the nice thing about M:I is that it doesn't have a problem with idiosyncracies, because it doesn't have back-compat issues. I just change it later and make sure it's sufficiently hard to use it that only the dedicated people know about it. :) Adam K 2009/1/28 David Golden <[email protected]>: > 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 > > >
