On Jan 27, 2009, at 5:47 PM, Michael G Schwern wrote:

A good solution is to have a single policy of what to do
(execute/ask/disallow) and the meta-file contain defaults if their executables
are not run.  This is analogous to how prompt() works.

As I said in my previous email, if I'm installing your code, I'm going to be running it, anyway. So why can't the build script be written in Perl?

It is also critical to realize that custom code parts would be considered *exceptional* rather than normal and the drive would be to eliminate them.
See below.

This is true now for Module::Build. The vast majority of Build scripts look something like this:

use Module::Build;

my $build = Module::Build->new(
    module_name        => 'FSA::Rules',
    license            => 'perl',
    create_makefile_pl => 'passthrough',
    create_readme      => 1,
    requires           => { perl            => 5.006_002 },
    configure_requires => { 'Module::Build' => '0.2701'  },
    build_requires     => {
        'Module::Build' => '0.2701',
        'Test::More'    => '0.17',
    },
    recommends         => {
        'GraphViz'       => '2.00',
        'Text::Wrap'     => 0,
        'Storable'       => '2.05',
        'B::Deparse'     => '0.61',
        'Test::Pod'      => '1.20',
      },

);
$build->create_build_script;

See? All metadata. So what does an alternate format buy you? As a Perl author, I'm more comfortable editing my build configuration in Perl than in YAML or JSON or just about anything else.

I wouldn't want it in SQL, though. Ick. Wrong hammer for this pylon. ;-)

The advantage of the meta-file is it can absorb more and more use cases things need less and less custom code. This is critical: it improves over time!

Custom code is already the exception. What would simplify the custom code problem, IMHO, is adding support for plugins to Module::Build.

name:           Foo-Bar
version:        from('lib/Foo/Bar.pm')
abstract:       from('lib/Foo/Bar.pm')
authors:
      - Michael G Schwern <schw...@pobox.com>
license:        perl
requires:
      everywhere:
              File::Spec:     0.8
              perl:           5.6.1
      os_is('Win32'):
              Win32::Thing:   1.23
      sub { -x "/usr/bin/mysql" }:
              DBD::mysql:     0

So if we had a plugin system in Module::Build, we'd be able to do something like this:

use Module::Build plugins => [qw(OS FS)];

Module::Build->new(
    module_name => 'Foo::Bar',
    license     => 'perl',
    requires    => [
        File::Spec => '0.8',
        perl       => '5.6.1',
        (os_is('Win32') ? (Win32::Thing => '1.23') : ()),
        (has_bin('mysql') ? (DBD::mysql => 0) : ()),
    ],
);

Hell, we could even have simple functions that return values, like:

    requires    => [
        File::Spec => '0.8',
        perl       => '5.6.1',
        os_requires('Win32', Win32::Thing => '1.23'),
        bin_requires('mysql', DBD::mysql => 0),
    ],

Much easier to write than YAML.

However, we can't just use a Perl program because it's Perl and can do
anything at all. This blows the whole point of a meta-file out of the water, that it can be trusted. That it can be read without executing arbitrary code.

Isn't that what META.yml is for already?

Best,

David

Reply via email to