On Saturday, March 8, 2003, at 11:41 AM, Jochen Wiedmann wrote:
thanks for the pointer Ken. I have carefully read the thread and found nothing that convinced me. In fact I have missed some arguments:
- data files generated by Data::Dumper can be evaluated in a "Safe" compartment.
It's not malicious code we're (at least, I'm) worried about, it's the fact that code is being eval-ed. As soon as you make it eval-able perl code instead of a static data definition language, someone is going to put something like
($^O =~ /Win/ ? Foo::Win32 : Foo::Generic)
in there, and now we don't have a static list of dependencies anymore. If it's not static, what's the point in extracting it out of the Makefile.PL?
That said, malicious code is probably a real issue too, because these files shouldn't be able to *do* anything, they should just contain some data. The hope is that these files will be used in lots and lots of situations by lots of different parties, and we can't make sure *all* of them use Safe.pm in a tight way. Nor is Safe.pm very tight in the first place. One need only look at the following to see why:
http://search.cpan.org/author/ABERGMAN/Safe-2.09/ Safe.pm#Some_Safety_Issues
- An XML Writer would be required by the module author only. An XML Reader is already part present on most systems, with a definitely growing number.
I'm not eager to write the code that senses around for whatever weird XML reader might be present on whatever weird system, though. And this says nothing about systems that were built and deployed three years ago, which won't have one unless we require them to install it.
- I recently started to have a look at Module::Build and I wholehearty support it: In particular, because it will finally simplify module installation on Windows and commercial Unix systems, where one typically doesn't have a C development environment. But my guess its most important problem for acceptance will be its dependence on "esoteric" modules like YAML or ExtUtils::ParseXS. (Esoteric == not part of the ActiveState repository, aka "target group") *I* (module author) had no problem installing these prerequisites, but I wouldn't like to receive 10 emails a week asking "How do I install these modules?"
I agree completely with these sentiments. If you look at the actual list of required dependencies for Module::Build, you'll see that they're all present in the perl 5.6.0 core. The other things like YAML and ParseXS are only *recommended* dependencies, but unfortunately CPAN.pm reports them as required.
(actually, this might be fixable in Module::Build rather than requiring a CPAN.pm patch.)
Note that M::B can use either the regular xsubpp script in core perl, or ExtUtils::ParseXS, which is a safer and more compartmentalized way to achieve the same thing.
In any case though, for the M::B project to move forward and do things that MakeMaker hasn't been able to do easily, it may require people to install some more modules.
- You think XML isn't human readable? What do you expect the typical joe user to do, if she or he finds an unknown file? Double-clicking it! In the case of XML that means, that a properly configured browser opens the file, formats it nicely, highlights tags, offers to hide or view sections.
That's true. I'm not sure I expect someone who doesn't know how to read a simple text file to be poking around in Perl module source directories much, though.
- You happy guys seem to live in a Perl-only world. My Envy! I don't and most other peoples also do. However, in a heterogenous world, a portable data format is worth much more than a data format that requires me to write a parser.
Why in the world would you be required to write a parser??
Your arguments seem to be sort of against YAML in the abstract - do you have a particular application involving the META.yml file that is going to be more difficult because of the choices that have been made?
I do appreciate your point of view, but I can also tell you that for every person that asks why we're not using XML for this, there's another person who's written me telling me how glad he/she is that we're not.
-Ken
