Hi Andreas, When I first read this message back in April, I was going to reply and tell you why I thought your version was all wrong. But now a month later, I found myself working on it, and came around completely to agree with what you've said. =)
I'm hoping to use YAML as the format for the metadata file, because I have no interest in inventing another serialization/markup format, and the following formats are unsatisfactory in some way or another: XML - too big a gun, too yucky Data::Dumper - requires an eval() to parse Storable - not human-readable Previously I was thinking that module developers would hand-build the metadata files, so I was a little worried about YAML's whitespace strictness, but if the files are going to be created automatically by the developers during the packaging process, the whitespace isn't really a concern. If anyone really thinks I really really have to use XML, speak up. On Tuesday, April 30, 2002, at 04:32 PM, Andreas J. Koenig wrote: >>>>>> On Sun, 28 Apr 2002 13:12:49 -0400, Michael G Schwern >>>>>> <[EMAIL PROTECTED]> said: > >> If may not be possible to get all the possible configuration problems >> down >> to just a static config file. You'll likely still need the ability for >> modules to call perl code for various stages of the build & >> installation. A >> good exercise would be to take something really complicated, like PDL >> or >> WxPerl and think "how would I do this in Module::Build"? > > I believe MakeMaker should be more or less preserved and a parallel > universe should be dedicated to *maintain metadata*. This parallel > world should be built *around* MakeMaker. On the developer's machine > you can always run MakeMaker without a security problem, because who > wrote that Makefile.PL again? So let the developer's MakeMaker write > metadata and distribute these within the distribution. The consumer > can then read the metadata and find a hint if Makefile.PL must be > executed or not. There are these clever packages like mod_perl that > just shine because they can run perl. No configuration options will > ever be enough to cover the really clever stuff. The parallel universe > can shine when it proves it can install the proverbial 80% of CPAN > with the metadata file. > > If done right, this will provide seemless integration of old and new > world. It will also provide the extensibility of MM and it will > provide metadata for 100% of CPAN, even for those cases that need > MakeMaker to run on the costumer's site. > >>> What other things need to be in the info-files? Module >>> (distribution) name should be there, but version should probably >>> not be (they're specified in the module files themselves). >>> Patches aren't relevant, of course. > > The metadata file should be redundant with the rest of the > distribution. It should be distributable separately with maximum > information. So, of course it should contain the version number. > > Of course, this is only my old rant and I never came around to work on > it. Feel free to follow a different vision... > > -- > andreas > -Ken
