Re: 'make dist' now adds META.yml
Hi, On Friday, March 7, 2003, at 03:04 AM, [EMAIL PROTECTED] wrote: Forgive my terseness, but this discussion has already been done in I wholeheartly understand your terseness. In fact it was what I expected. That's why my first sentence was to apologize. However, I still disagree and I think the task of a mailing list is to allow me expressing my opinions. Quoting Ken Williams [EMAIL PROTECTED]: For those that want to see a previous incarnation of this discussion, see http://archive.develooper.com/[EMAIL PROTECTED]/msg00405.html 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. - 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 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? - 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. - 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. Jochen
Re: 'make dist' now adds META.yml
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
Re: 'make dist' now adds META.yml
On Sat, Mar 08, 2003 at 07:25:16PM +0100, Jochen Wiedmann wrote: Quoting Ken Williams [EMAIL PROTECTED]: Why in the world would you be required to write a parser?? Because I possibly would want to read these files automatically? Your original posting explicitly stated that this is just what they are made for. *You* do not need to write a parser. Parsers are already written. perl -MYAML -e 'print Dumper YAML::LoadFile(META.yml)' Perl http://search.cpan.org/author/INGY/YAML-0.35/ Python http://wiki.yaml.org/yamlwiki/PurePythonParserForYaml Ruby http://yaml4r.sourceforge.net/ 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. I absolutely believe that. The difference is, that in 2 or 3 years, when an XML parser (however wierd) will be installed on any uptodate Perl system, noone will ask Why are we using XML and not YAML?. In the contrary case the question will stick forever, because you have a lot of users as stupid as me. It doesn't take much prophecy to foresee that. Its popular is not a compelling argument. Otherwise we'd all be using Java and XML on Intel machines running Windows and nobody would be bothering with Module::Build we'd just be clunking along with MakeMaker. If all things were equal between YAML and XML then yes, we'd go with the more popular one. But they're not equal and popularity doesn't weigh much. We must have the courage to try new things if we think they will work out better.
Re: 'make dist' now adds META.yml
On Thu, Mar 06, 2003 at 10:03:27AM -0600, Ken Williams wrote: Well, some modules are core in 5.8 but not in 5.6, etc., so this wouldn't reflect reality on many systems. How about we change that to something like: core: 5.6.0 Which indicates at what perl version *some* version of this module went into the core. So, a module like Dumpvalue.pm, which is core in 5.6 but not in 5.005, could be installed into 'site' dirs for 5.005, and 'perl' for 5.6. This makes sense. MakeMaker can't [1] do it because it doesn't have that information, but Module::Build can. [1] It could be added but its not worth the effort.
Re: 'make dist' now adds META.yml
On Friday, March 7, 2003, at 03:04 AM, [EMAIL PROTECTED] wrote: Forgive my terseness, but this discussion has already been done in all possible permutations. Below are the conclusions reached. If you wish to continue discussing, I'd be happy to do it in private but I really, really DO NOT WANT ANOTHER XML VS YAML DISCUSSION. Not on this list anyway. For those that want to see a previous incarnation of this discussion, see http://archive.develooper.com/[EMAIL PROTECTED]/msg00405.html -Ken
Re: 'make dist' now adds META.yml
On Thursday, March 6, 2003, at 08:38 AM, [EMAIL PROTECTED] wrote: The META.yml file is intented to be compatible with Module::Build's and currently looks something like this: #XXX This is a prototype!!! It will change in the future!!! X# name: ExtUtils-MakeMaker version: 6.06_03 version_from: lib/ExtUtils/MakeMaker.pm installdirs: perl requires: File::Spec:0.8 File::Basename:0 DirHandle: 0 Pod::Man: 0 distribution_type: module generated_by: ExtUtils::MakeMaker version 6.06_03 The only thing that sticks out at me is the installdirs key - is that really meta-data about the distribution? It seems like it's a choice the user makes when installing. Also, there's no license key here. Is it possible to generate that from anything? -Ken
Re: 'make dist' now adds META.yml
On Thu, Mar 06, 2003 at 09:00:06AM -0600, Ken Williams wrote: The only thing that sticks out at me is the installdirs key - is that really meta-data about the distribution? It seems like it's a choice the user makes when installing. If installdirs: perl then its a core module. Site means its not. The user can change it from there if they like, but there is a default installation choice made by the author. Just tossed it in there because it was easy. Also, there's no license key here. Is it possible to generate that from anything? MakeMaker doesn't have any license information. :(
