Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Perl6 - Module::Build

by dragonchild (Archbishop)
on May 27, 2005 at 15:18 UTC ( #461105=perlmeditation: print w/ replies, xml ) Need Help??

There's no module installer in Pugs, yet, so I'm going to write one. Since the directory tree hasn't been laid out yet, this is your chance to maybe influence how P6 will build C6PAN module and where they will be installed. What I'm looking for is:
  • Specifications - what do you want it to do? How do you want it to do it?
  • Tests - you give me the tests, I write the code.

You don't need to be involved in Pugs to help with this. Just respond with what you'd love to see this thing to. Everything (except what's listed below) is up for debate.

Decisions:

  • I'm going to take a page from the Module::Build folks and make this PurePerl.

This discussion is continued at Perl6 - Distribution builder/installer.


  • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
  • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

Comment on Perl6 - Module::Build
Re: Perl6 - Module::Build
by Juerd (Abbot) on May 27, 2005 at 15:43 UTC

    Anything will work, as long as it makes installing a non-system-wide copy very, very easy. Without the need of specifying a prefix. In fact, perhaps homedir installation (~/.perl6/lib/...) should be made default, and whatever directory is used for that should be in @*INC by default too.

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      I second the home dir installation idea.  Maybe not default, but definitely have an easy syntax to do home dir installations; something like perl Makefile.PL install_dir   (replace Makefile.PL with whatever makes sense (my brain is a little fried right now from 12+ hours of trying to shoehorn XS modules into a poorly configured machine); hopefully you get the idea).

      Update:  I just saw this quote in The St. Larry Wall Shrine, the irony was too much to pass up...

      "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
      --Larry Wall in <1992Aug26.184221.29627@netlabs.com>

Re: Perl6 - Module::Build
by itub (Priest) on May 27, 2005 at 16:11 UTC
    Maybe it would be nice to have an easy way of installing more than one version of a module.
      for perl5 there is only that does just that.
Re: Perl6 - Module::Build
by brian_d_foy (Abbot) on May 27, 2005 at 18:07 UTC

    Although the directory tree is not formally laid out, there has been a lot of talk about it. The big changes that remember from the discussions are:

    • Install multiple versions at the same time
    • Tag modules with author name
    • Uninstall capabilities

    However, the installation targets shouldn't influence your design that much.

    Don't limit your discussion to Perlmonks: a lot of other parts of the Perl universe have to work with whatever you come up with. You'll probably also want to work with (not separately) from the current Module::Build folks who have already thought a lot about this stuff.

    Good luck :)

    --
    brian d foy <brian@stonehenge.com>
Re: Perl6 - Module::Build
by theorbtwo (Prior) on May 27, 2005 at 19:09 UTC
    In no purticular order, things that I would like to see:
    • Pure perl is the right decision. For that matter, as far as possible, it should have no external dependencies. (Such as make.)
    • I would suggest a design using /lots/ of mix-in modules -- it should be possible to install on a system with win32-ish names for things (.exe, .obj, .dll), but a unixish directory tree, by plugging and playing the approprate modules.
    • It should be possible to get lots of metadata without running any free-form code, or it should be possible to run the code within the non-IO playground.
    • It should be possible to express a very rich set of dependency information. Most importantly, it should be possible to express dependencies outside of the perl world -- on C-ish libraries, on implementation details, and on OS. ("This library requires pugs on win32 and the library http://www.libsdl.org with a version between 3.1 and 4.")


    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Re: Perl6 - Module::Build
by Ovid (Cardinal) on May 27, 2005 at 19:27 UTC

    Great news! Thanks. In no particular order:

    • Support for .buildrc so commonly used build requirements don't need to be respecified every time.
    • Finer granularity on requirements: required, required for build, required if a particular feature is requested, required for tests, recommended, etc.
    • Built in support for test coverage and code profiling (when such is available).
    • Uninstall (should probably keep a database of installation history, too).

    Cheers,
    Ovid

    New address of my CGI Course.

      What does test coverage have to do with module installation?

        Test coverage has nothing to do with module installation. However, build systems are for both those who install modules and those who create modules. Otherwise, it might make more sense to call this Module::Install or Module::Create. Since you can't have the former without the latter, why create a build system that only caters to one segment? I am not suggesting that this be one of the first features put in there, but it would be a valuable one.

        Test coverage is an important (but neglected) part of ensuring software quality. Any tool that makes it easier to provide better quality software can only help Perl.

        Cheers,
        Ovid

        New address of my CGI Course.

        Well, users need to run tests, and developers shouldn't be encouraged to break TEST_VERBOSE=1 .... the less developers have to invent, the more useful cpan-tester results become

        update: what I'm trying to say is that everyone needs a good uniform experience from the start, so they can focus on more important things

        MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
        I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
        ** The third rule of perl club is a statement of fact: pod is sexy.

Re: Perl6 - Module::Build
by Corion (Pope) on May 27, 2005 at 19:33 UTC

    Since you're going pure Perl, please don't repeat the mistake of Module::Build of not having a dry-run and no trace of attempted/failed steps. make -n tells me in great detail what it will try, and make itself tells me what it tried and how it failed. Both are very necessary when debugging the installation.

    Update: Another important addition are two hard rules for the Perl code:

    • No user interaction without defaults
    • No loops, or at least no possibly infinite loops when the installation is not run interactively

    A good way for that might be specialized functions like prompt_path and prompt_executable, that implement the looping themselves.

      You make it sound as if Module::Build is somehow coded to _not_ allow dry runs. I don't think this was a design decision Ken made, it's simply not in the code base at present.

      There is a "fakeinstall" build target you can use to get a partial dry run (just of the parts done by ExtUtils::Install, aka module installation). I'm sure patches are welcome to expand dry-run functionality ;)

      • No user interaction without defaults
      • No loops, or at least no possibly infinite loops when the installation is not run interactively

      Could you please elaborate on these points? What situation(s) are you trying to avoid? Those sound like experience-based rules ...


      • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
      • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

        I run CPAN smoke tests, and the alarm() call has problems on Win32 Perl, so Makefile.PL does not get timed out when doing a CPAN smoke. Both rules have been evolved from the broken Makefile.PL that is the tradition of mod_perl, which dives into an infinite loop asking me for the location of httpd, over and over again, without a default and without user interaction. The subsequently generated long error email (after I kill the runaway process) then gets bounced back to me by x.perl.org in its entirety because it's too large.

        To prevent authors of Makefile.PL from doing these stupid steps, I came up with these rules.

        The first rule makes authors think about providing sensible defaults or even making the Makefile.PL actively search instead of always asking the user. This is a passive measure to make Makefile.PL find things even in absence of guidance by a user.

        The second rule actively prevents authors from writing potentially infinite loops asking the same question, again and again, without ever getting an answer because there is no user.

Re: Perl6 - Module::Build
by PodMaster (Abbot) on May 27, 2005 at 20:30 UTC
    Currently both ExtUtils::MakeMaker and Module::Build complicate the install step (which is just a copy operation) by using some XS modules (Cwd), which means that you can't upgrade those modules on platforms like win32 (can't delete .dll while it's use). I'd like to not see this mistake repeated :)

    Another thing I'd like to see is good detection of compilers, headers, external libraries, ... The developer would only specify what his module needs to function (libexpat, version 2) and the user would automatically be prompted if some things are missing (or might be named differently).

    A user shouldn't be able to get past the Makefile.PL step if he's missing a C compiler, expat.h, or version 2 of libexpat ...

    With regards to tests, a developer need only write something like

    test_prompt( "need_socket", "Needs to create sockets to blah.com", "default if no default from config" [ qw[t/sock1. t/sock2.t]] ); test_prompt( "need_server_socket", [qw[t/servsock1. t/servsock2.t]] );
    And a user would be prompted if he'd like to run those tests, with a defaults (need_socket, need_server_socket) being provided through a config file.

    Also see Module::Install for ideas.

    update: Whether to build manpages/htmldocs should also be user configurable

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

      Now I know I'm not the only one with problems with Cwd.

      While it certainly should be built into perl.dll (speaking of Win32), it is not, and some non-trivial usages of Cwd from Perl built into C makes my program even segfault.
      I therefore trade portability and use Win32::GetCwd which in turn built into perl.dll

      Also, during its execution it constantly checks for $^O, suspecting my script to start on Win32 and then continue working on VMS.

      FWIW Cwd is a perfect example of poorly designed module, however visually it looks sane but implemented insane, yet its task is trivial.

Re: Perl6 - Module::Build
by jonadab (Parson) on May 28, 2005 at 10:07 UTC

    In addition to what everyone else has said, I'd like to NOT have to re-install modules every time I upgrade to a new Perl or a new Pugs or a new Parrot or whatever.

Re: Perl6 - Module::Build
by Jaap (Curate) on May 28, 2005 at 12:18 UTC
    I might be alone in this, but i'd like to see some way of installing it in one step, without make && make test && make install (or the Module::Build equivalents).
      Isn't that make install?

      MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
      I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
      ** The third rule of perl club is a statement of fact: pod is sexy.

        I never knew that worked. Why do they always say make && make test && make install then?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://461105]
Front-paged by kutsu
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2014-12-20 09:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (95 votes), past polls