FAQ
Hi,

I find this module intriguing.

In my understanding, the complexity of Module::Build piled up
because the same tool tries to cover both installation and
authoring use cases.

I believe the Dist::Zilla approach is a better way to take care
of authoring: a separate toolchain that can be as complex as the
author would prefer. The installer can then be trivial, as indeed
it should; as well as pure Perl – as indeed, it should.

So Dist::Zilla plus the *idea* of Module::Build::Tiny seem to
fulfil the original concept of Module::Build better than that
module itself ever has.

But is the implementation up to par?

Essentially: if I’m using Dist::Zilla for authoring, what regular
features not explicitly mentioned in MBT’s POD would I have to
avoid? Do things like optional or build-/test-only deps work?
(I’d assume these do.) Or can I assume that everything will work
unless otherwise pointed out?

I could answer this for myself if I had *exact* understanding of
how much of the work falls upon the .PL at install time, and how
many of the toolchain features are implemented in the CPAN client
and thus unaffected by MBT’s minimalism.

So the answer to that is what I’d like.

(I’d also be interested in whether any omissions mentioned in the
POD are design choices or the idea is to add them in the future,
and which if so.)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

Search Discussions

  • Eric Wilhelm at Aug 29, 2011 at 7:47 am
    # from Aristotle Pagaltzis
    # on Sunday 28 August 2011 22:50:
    In my understanding, the complexity of Module::Build piled up
    because the same tool tries to cover both installation and
    authoring use cases.
    I've often had that thought, though I would say that M::B definitely
    suffers from being a mature codebase largely lacking its original
    author and large amounts of test coverage where small changes could
    break the CPAN -- so, that tends to stifle innovation (in my personal
    experience.) The compat code (involving various forms of Makefile.PL
    workarounds) is also a burden, as is coding to be compatible with
    anything older than 5.8.

    But I don't think there are really enough authoring features for that to
    be a major source of complexity. The "subclassing as customization"
    design leaves a lot to be desired and makes it difficult to ever change
    or refactor the internals API without breaking someone's distribution.
    There is also almost a decade of transition coded into it (e.g.
    TAP::Harness vs Test::Harness) and a lot of code just to guard against
    being used in ridiculously old installations.

    Plus, strange things that happen when you mess with PERL5LIB / -I / 'use
    lib', etc and expect that to propagate throughout your tests across
    processes regardless of whether you're running red hat or not. We'll
    see if MBT has to run the same guantlet.
    I believe the Dist::Zilla approach is a better way to take care
    of authoring... So Dist::Zilla plus the *idea* of Module::Build::Tiny
    seem to fulfil the original concept of Module::Build better than that
    module itself ever has.
    If you're using Dist::Zilla, you *should* not need anything besides
    META.json to install a simple module if you just set dynamic_config=0.
    (This "should" is, of course, largely unimplemented.)

    Also, I think that M::B is better as a customizable deployable build
    tool than as an author tool. I think it was even conceived as just
    that and only years of feature creep have added a lot of author tools.
    But is the implementation up to par?
    ...
    (I’d also be interested in whether any omissions mentioned in the
    POD are design choices or the idea is to add them in the future,
    and which if so.)
    There might be some trouble being compatible with some of the more
    obscure features of buildrc and the env (which somebody always seems to
    have setup in a way which you have never thought necessary or logical.)
    It does seem to have factored-out many functions which M::B had as
    (maybe misplaced) methods.

    Overall, it looks interesting, but I would hope that it at least adds
    some runtime support if not also C/XS.

    Without the ability to have dynamic prereqs or build C/XS, why do you
    need a Build.PL at all? You have to assume that the client supports
    'configure_requires' or the user has already installed MBT for this to
    work. If the Build.PL is a compatibility workaround, that seems like a
    weird niche to me because needing 'configure_requires' means you need a
    client from the last few years and 'dynamic_config' has been around
    longer.

    Sadly, cpanm seems to not support dynamic_config. I'm not sure whether
    one of the other two clients can "satisfy prereqs from META, run
    `prove -lr t`, and install the files from lib/" yet.

    --Eric
    --
    "Insert random misquote here"
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • David Golden at Aug 29, 2011 at 5:01 pm

    On Mon, Aug 29, 2011 at 1:50 AM, Aristotle Pagaltzis wrote:
    I find this module intriguing.
    Thank you. It grew out of Acme::Module::Build::Tiny -- which was an
    exercise to determine the *minimal* API that Build.Pl/Build needed to
    allow the toolchain to install a module. (Thus cutting out all the
    authoring cruft that bled into Module::Build over the years.) Kudos
    to Leon for taking it from Acme and making it real.
    In my understanding, the complexity of Module::Build piled up
    because the same tool tries to cover both installation and
    authoring use cases.
    That is one part of the complexity (OO subclassing is the other part).
    I suspect that the majority of the lines of code are due to author
    support, not installation support.
    But is the implementation up to par?

    Essentially: if I’m using Dist::Zilla for authoring, what regular
    features not explicitly mentioned in MBT’s POD would I have to
    avoid? Do things like optional or build-/test-only deps work?
    (I’d assume these do.) Or can I assume that everything will work
    unless otherwise pointed out?
    I haven't used it in my own modules. With Dist::Zilla to hide the
    ugliness of Makefile.PL from me, I just let it use that. Most if not
    all of what dzil does should still work. The exception would be
    plugins that want to hack directly on a generated Makefile.PL (e.g.
    Dist::Zilla::Plugin::DualLife).
    I could answer this for myself if I had *exact* understanding of
    how much of the work falls upon the .PL at install time, and how
    many of the toolchain features are implemented in the CPAN client
    and thus unaffected by MBT’s minimalism.
    MBT uses many external libraries (many core, some not yet core :-) to
    do what it does. Here's a very simplistic version of the install
    process (not specific to MBT):

    * PL -- resolve any dynamic configuration issues; write prereq data
    into somewhere the toolchain can find it (MYMETA is the new standard,
    but EUMM and MB had their own custom ways to do it); alert users to
    things missing

    * make/Build -- assemble all files to be installed into blib/ -- for
    pure perl module, this is usually just copying from lib/, unless there
    are other foo.PL modules to generate foo.pm; for C/XS modules, a lot
    of libraries are needed to compile the XS, location the C compiler,
    etc. This is ugly, complicated stuff to get right portably, which is
    why MBT doesn't do it (yet)

    * test -- run tests in t with Test::Harness (or possibly
    TAP::Harness); the make/Build tools is responsible for determining the
    list of files to run, including possible recursion in t/, as well as
    setting any necessary environment variables (e.g. PERL5LIB)

    * install -- assemble a manifest of files to be installed from blib/
    and hand off to ExtUtils::Install to do the dirty work

    One of the hard parts throughout the stuff above is getting the
    library paths correct. For installation, that means sorting out where
    to install given PREFIX/INSTALL_BASE or custom library paths. For
    testing, that means ensuring the right PERL5LIB/PATH given the various
    ways they could be set, e.g. in an original PERL5LIB, via "-I bar"
    flags to "perl Makefile.PL" or "perl Build.PL", or via "use lib"
    statements in *.PL

    (More that you wanted to know, perhaps.)
    (I’d also be interested in whether any omissions mentioned in the
    POD are design choices or the idea is to add them in the future,
    and which if so.)
    I don't personally plan to do more work on it now that the
    Build.PL/Build API has been demonstrated. I'll leave that to Leon to
    respond to. Most of the original Acme::Module::Build::Tiny
    limitations were design decisions to stay consistent with the Tiny
    philosophy of providing 90% of the functionality of the "heavy" module
    in a fraction of the code. I wasn't trying to rewrite M::B. I was
    trying to write a new, minimalist replacement sufficient for most
    things on CPAN that didn't require any changes to
    CPAN/CPANPLUS/cpanminus.

    Eric raises the question "why bother" and I think for module authors,
    at least right now, there is no burning platform to switch. Schwern
    has been trying to get people to stop using EU::MM for years and I
    think the MBT is a stepping stone towards that vision. Once it
    figures out the hard bits of interacting with the toolchain, it should
    be relatively easy for it or successors to add the missing features
    within a well-defined framework.

    Perl 5.10.1 supports configure_requires and is already unsupported by
    P5P, though the Perl toolchain maintainers have an informal agreement
    to support older Perls (5.6 at least, though that may shift to
    something in the 5.8 series with decent Unicode support before long).

    By the time that MBT has enough track record for widespread adoption,
    I would hope that Perl 5.10.1 becomes the oldest perl supported by the
    toolchain and then MBT or other Build.PL solutions will be the future
    and we'll finally put a stake in the heart of ExtUtils::MakeMaker.

    -- David
  • Eric Wilhelm at Aug 29, 2011 at 6:25 pm
    # from David Golden
    # on Monday 29 August 2011 08:07:
    Eric raises the question "why bother" and I think for module authors,
    at least right now, there is no burning platform to switch.
    I think you misunderstand my point. Given dynamic_config support, there
    is no need for a $builder_or_maker.PL for the simple case.
    I was trying to write a new, minimalist replacement sufficient for
    most things on CPAN that didn't require any changes to
    CPAN/CPANPLUS/cpanminus.
    As for a demonstration of implementing the Build.PL interface: yes.

    But I think the CPAN clients should eliminate it by supporting
    dynamic_config. I haven't experimented to see what the current state
    of this is, but CPAN.pm has dynamic_config support in the prereqs (not
    sure about test+install.)

    I think the most complicated part is supporting whatever
    builder+installer assumptions people have encoded into their
    configurations -- maybe the client could read buildrc?

    --Eric
    --
    I arise in the morning torn between a desire to improve the world and a
    desire to enjoy the world. This makes it hard to plan the day.
    --E.B. White
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • David Golden at Aug 29, 2011 at 6:34 pm

    On Mon, Aug 29, 2011 at 2:25 PM, Eric Wilhelm wrote:
    I think the most complicated part is supporting whatever
    builder+installer assumptions people have encoded into their
    configurations -- maybe the client could read buildrc?
    For that, I'd prefer to see a new way for CPAN clients to share common
    configuration information. Think how ~/.gitconfig provides config
    info used by lots of git ecosystem tools. I'd like that for CPAN so
    one isn't configuring mirrors, INSTALL_BASE, etc. for each client
    individually. I had some stub code for that, but have set it aside in
    favor of other projects.

    I don't think .buildrc is the answer, though. It has a number of
    limitations, particularly with respect to paths with spaces.

    -- David
  • Leon Timmermans at Aug 30, 2011 at 12:30 am

    On Mon, Aug 29, 2011 at 7:50 AM, Aristotle Pagaltzis wrote:
    I find this module intriguing.
    I'm happy to hear that :-)
    In my understanding, the complexity of Module::Build piled up
    because the same tool tries to cover both installation and
    authoring use cases.
    There are many things that contribute to that. I think there's a more
    general everything-and-the-kitchensink issue going on in
    Module::Build. In Module::Build::Tiny I'm trying to go into the
    opposite direction: modularize everything that's reusable so the
    central module is actually quite small and simple.
    But is the implementation up to par?
    Not yet, but it's getting close. I'm still dealing with some
    portability issues, but the core idea of it seems sound. For a pure
    perl module that runs only on Unix on perl 5.10.1 or higher, it should
    be up to par now already. If not bug reports are welcomed. I'm only
    using it for two relatively unimportant modules so far, but I'm
    planning to try it with more modules as soon as the known issues have
    been ironed out.
    Essentially: if I’m using Dist::Zilla for authoring, what regular
    features not explicitly mentioned in MBT’s POD would I have to
    avoid? Do things like optional or build-/test-only deps work?
    (I’d assume these do.) Or can I assume that everything will work
    unless otherwise pointed out?
    Dependencies are handled in the CPAN client (and written by
    Dist::Zilla), so that should be no problem.
    (I’d also be interested in whether any omissions mentioned in the
    POD are design choices or the idea is to add them in the future,
    and which if so.)
    HTML documentation support should definitely be added before I'd
    consider it finished; the others are design choices. That said, I'm
    not opposed to implementing any of the others if it can be done in a
    tiny enough way. If I end up adding extensions (which would
    essentially mean a rewrite of MBT) then even the tininess restriction
    would be gone for the other ones I guess.
    On Mon, Aug 29, 2011 at 5:07 PM, David Golden wrote:
    for C/XS modules, a lot
    of libraries are needed to compile the XS, location the C compiler,
    etc. This is ugly, complicated stuff to get right portably, which is
    why MBT doesn't do it (yet)
    I have a prototype tying together ExtUtils::CBuilder and
    ExtUtils::ParseXS, it only supports simple XS modules and is so far
    only tested on Linux, but it was pleasantly simple to implement.
    Eric raises the question "why bother" and I think for module authors,
    at least right now, there is no burning platform to switch. Schwern
    has been trying to get people to stop using EU::MM for years and I
    think the MBT is a stepping stone towards that vision. Once it
    figures out the hard bits of interacting with the toolchain, it should
    be relatively easy for it or successors to add the missing features
    within a well-defined framework.
    Yeah, most of all MBT is an experiment. It's proof that writing a
    Build.PL implementation doesn't have to be all that hard. It's a
    process of getting the modules out there that make it easier. Being a
    viable alternative to existing builders is a bonus really. At some
    point there will be a non-tiny successor that will do everything
    Module::Build can and more without becoming an monolith.
    Perl 5.10.1 supports configure_requires and is already unsupported by
    P5P, though the Perl toolchain maintainers have an informal agreement
    to support older Perls (5.6 at least, though that may shift to
    something in the 5.8 series with decent Unicode support before long).
    Yeah, I think that on the medium timescale 5.8's lack of
    configure_requires is the main handicap. Fortunately that problem will
    fix itself if given enough time.

    Leon
  • Leon Timmermans at Aug 30, 2011 at 4:12 pm

    If you're using Dist::Zilla, you *should* not need anything besides
    META.json to install a simple module if you just set dynamic_config=0.
    (This "should" is, of course, largely unimplemented.)
    I hope a lot of Module::Built::Tiny will end up getting reused for that purpose.
    Overall, it looks interesting, but I would hope that it at least adds
    some runtime support if not also C/XS.
    If not, there will be another Build.PL implementation that does.
    Sadly, cpanm seems to not support dynamic_config. I'm not sure whether
    one of the other two clients can "satisfy prereqs from META, run
    `prove -lr t`, and install the files from lib/" yet.
    In the meta spec 2.0, dynamic_config is defined more strictly than in
    previous versions; it only refers to the configuration phase. There
    are some complications with static building/installing.

    Leon

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmodule-authors @
categoriesperl
postedAug 29, '11 at 5:50a
activeAug 30, '11 at 4:12p
posts7
users5
websitecpan.org...

People

Translate

site design / logo © 2021 Grokbase