FAQ
For quite some time I've created modules for internal use and I don't bother
with h2xs anymore for non-xs modules and I just copy-n-paste some existing
Makefile.PL I have from another package. As a result of some choice a while
back all my modules use Module::Install.

I guess I like the declarative format of Module::Install and features like
"test_requires", "install_share". Otherwise, I don't really care how the
module is built and installed as long as it works. And I have not in a long
time looked at the the different approaches in detail.

So, I'm curious. Is there any kid of consensus on what to use for new
modules and why? Or is it still mostly a matter of opinion?

--
Bill Moseley
moseley@hank.org

Search Discussions

  • Jerry D. Hedden at Mar 22, 2010 at 7:45 pm
    For the modules I put on CPAN, I use ExtUtils::MakeMaker/Makefile.PL
    because it is universally installed on all Perl versions that I
    support, and I have not found a need to migrate to something else.
  • Hans Dieter Pearcey at Mar 22, 2010 at 7:47 pm

    On Mon, 22 Mar 2010 12:35:56 -0700, Bill Moseley wrote:
    So, I'm curious. Is there any kid of consensus on what to use for new
    modules and why?
    No. The closest is "don't use MakeMaker", but even that's something people
    will still argue about.

    hdp.
  • Andy Lester at Mar 22, 2010 at 7:49 pm

    On Mar 22, 2010, at 2:46 PM, Hans Dieter Pearcey wrote:

    No. The closest is "don't use MakeMaker", but even that's something people
    will still argue about.
    And for module starting you have both Module::Starter and Dist::Zilla.

    --
    Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance
  • David Golden at Mar 22, 2010 at 7:51 pm

    On Mon, Mar 22, 2010 at 3:35 PM, Bill Moseley wrote:
    So, I'm curious. Is there any kid of consensus on what to use for new
    modules and why?  Or is it still mostly a matter of opinion?
    It's completely a matter of opinion. Schwern, who maintains
    ExtUtils::MakeMaker, has said in the past that people should be using
    Build.PL. Module::Install gives EU::MM a friendlier interface -- I'd
    even say a new lease on life -- at the cost of increased complexity
    from its black box and the risk that you, as a distribution the
    author, might have to re-release everything if a bug is discovered in
    Module::Install. Module::Build has gotten much smoother and there's
    little that Module::Install does that it can't do now (e.g.
    File::ShareDir support), but still has a bootstrap problem for users
    of Perl < 5.10.1 who haven't upgraded CPAN/CPANPLUS and thus don't
    have support for "configure_requires".

    I've started using Dist::Zilla, which you can think of as a
    distribution compiler. It generates all the boilerplate cruft for
    you, including either a Makefile.PL or Build.PL. It has the benefits
    of Module::Install of a simpler, declarative interface (actually, just
    an INI style config file), without the downside of inflicting
    Module::Install on people who use your module. Unfortunately, right
    now it's only good for pure Perl distros with only static
    prerequisites (that describes most of CPAN, though).

    So... my opinion is:

    (a) never write an ExtUtils::MakeMaker yourself, it's just too painful
    to get right

    (b) if you have to do anything "custom" in your build or test process
    -- strongly consider Module::Build because you can customize in Perl,
    which makes life much easier

    (c) if you have to do dynamic prereqs or are building XS, use either
    Module::Install or Module::Build.

    (d) if you are doing pure perl with static prerequisites, seriously
    consider Dist::Zilla, or use whichever of Module::Build or
    Module::Install that you're most familiar with.

    (e) If you really care about separating requires and build_requires
    dependencies for downstream users and OS packagers, use Module::Build,
    which is the only thing that always does it correctly and is supported
    by CPAN and CPANPLUS. (There is a hack to add BUILD_REQUIRES to
    ExtUtils::MakeMaker, but it's recent and not well supported.)

    -- David
  • Dominique Dumont at Mar 22, 2010 at 8:11 pm

    Le lundi 22 mars 2010 20:50:51, David Golden a écrit :
    Module::Install gives EU::MM a friendlier interface -- I'd
    even say a new lease on life -- at the cost of increased complexity
    from its black box and the risk that you, as a distribution the
    author, might have to re-release everything if a bug is discovered in
    Module::Install.
    Module::Install raises a lot of problems downstream. I often hear Debian
    packagers complaining about it.

    Module::Build works fine and does not raise such problems.

    HTH

    Dominique
  • Jonathan Yu at Mar 22, 2010 at 8:22 pm
    Speaking also as a Debian packager, and notwithstanding Dominique's
    comments that we dislike Module::Install, I'd like to provide some
    additional clarification:
    On Mon, Mar 22, 2010 at 4:11 PM, Dominique Dumont wrote:
    Module::Install raises a lot of problems downstream. I often hear Debian
    packagers complaining about it.
    This is true, however, it's more about the fact that there are
    multiple different versions of Module::Install floating around in our
    packages (since they are embedded with each distribution, by its
    nature). Subsequently, sometimes we've discovered bugs that we need to
    add overrides for during building, cf.
    http://pkg-perl.alioth.debian.org/debhelper.html

    I think one other "issue" is that people are upset with the idea of
    having to add copyright information for files in
    inc/Module/{Install/*,Install.pm}, but this is largely mitigated with
    the copy-and-paste stuff here, cf.
    http://pkg-perl.alioth.debian.org/copyright.html

    However, the Module::Install maintainers have been on friendly terms
    with the pkg-perl group and I know of no outstanding issues we have
    with its usage. If there are, then it's incumbent upon us to report
    bugs against Module::Install accordingly, and coordinate with them to
    find a solution that makes everyone happy.
    Module::Build works fine and does not raise such problems.
    Module::Build's new bundling feature provides the same advantages and
    many of the same disadvantages involved with Module::Install. However,
    I have not seen its usage really out "in the wild" as of yet.

    Cheers,

    Jonathan
  • Eric Wilhelm at Mar 23, 2010 at 12:31 am
    # from Jonathan Yu
    # on Monday 22 March 2010 13:22:
    Module::Build's new bundling feature provides the same advantages and
    many of the same disadvantages involved with Module::Install. However,
    I have not seen its usage really out "in the wild" as of yet.
    The bundling in Module::Build is fundamentally different from bundling
    Module::Install in that the installed Module::Build is used if it is
    newer than the bundled version. Therefore, the bundled stuff will only
    ever be used when you have a cpan client with no 'configure_requires'
    support.

    It is currently labeled 'experimental' mostly for lack of testing. I'm
    not aware of any modules on the CPAN using it. I guess someone could
    ship a purely dummy distro and just see what sort of results they get
    from cpantesters.

    --Eric
    --
    [...proprietary software is better than gpl because...] "There is value
    in having somebody you can write checks to, and they fix bugs."
    --Mike McNamara (president of a commercial software company)
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • Curtis Jewell at Mar 23, 2010 at 6:42 am
    The problem is, most sane CPANtesters filter out Perl::Dist::*, so
    Perl-Dist-WiX-* does not get tested (and rightfully so)

    I'm bundling M::B in that distribution because the distribution has a
    sharedir.

    --Curtis
    On Mon, 22 Mar 2010 17:30 -0700, "Eric Wilhelm" wrote:
    # from Jonathan Yu
    # on Monday 22 March 2010 13:22:
    Module::Build's new bundling feature provides the same advantages and
    many of the same disadvantages involved with Module::Install. However,
    I have not seen its usage really out "in the wild" as of yet.
    The bundling in Module::Build is fundamentally different from bundling
    Module::Install in that the installed Module::Build is used if it is
    newer than the bundled version. Therefore, the bundled stuff will only
    ever be used when you have a cpan client with no 'configure_requires'
    support.

    It is currently labeled 'experimental' mostly for lack of testing. I'm
    not aware of any modules on the CPAN using it. I guess someone could
    ship a purely dummy distro and just see what sort of results they get
    from cpantesters.
    --
    Curtis Jewell
    swordsman@csjewell.fastmail.us

    %DCL-E-MEM-BAD, bad memory
    -VMS-F-PDGERS, pudding between the ears

    [I use PC-Alpine, which deliberately does not display colors and pictures in HTML mail]
  • Terrence Brannon at Aug 2, 2011 at 4:12 pm

    On Mon, Mar 22, 2010 at 3:35 PM, Bill Moseley wrote:

    For quite some time I've created modules for internal use and I don't
    bother with h2xs anymore for non-xs modules and I just copy-n-paste some
    existing Makefile.PL I have from another package. As a result of some
    choice a while back all my modules use Module::Install.

    I guess I like the declarative format of Module::Install and features like
    "test_requires", "install_share". Otherwise, I don't really care how the
    module is built and installed as long as it works. And I have not in a long
    time looked at the the different approaches in detail.

    So, I'm curious. Is there any kid of consensus on what to use for new
    modules and why? Or is it still mostly a matter of opinion?
    Dist::Zilla!

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmodule-authors @
categoriesperl
postedMar 22, '10 at 7:36p
activeAug 2, '11 at 4:12p
posts10
users10
websitecpan.org...

People

Translate

site design / logo © 2021 Grokbase