Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Module::Install 0.69 - The Deprecation Release 20 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • The realisation that author's won't upgrade their modules to pick up improvments to M:I should have been something I understood earlier.

    I knew you'd eventually come around!

    • I think this whole debate serves as a useful lesson beyond this single point though.

      The point I understood early that I think you took a while to realize is that you can't educate the users. You can't expect an install to fail and have the user learn about Module::Build and install it. We saw the same problem with PREFIX.

      What I misunderstood is that you can't educate the authors either. I held authors to a higher standard than users and figured that we could at least educate this more limited audience. And

      • The point I understood early that I think you took a while to realize is that you can't educate the users.

        I reject the idea that users are born knowing how to configure and run CPAN to install a distribution, but somehow that magical education stops when they run into problems. If that were true, I wouldn't have a job at a media company dedicated to the proposition that we can publish information for users to educate themselves.

        • Let me rephrase.

          You can educate some of the users some of the time, but you can't educate all of the users all of the time.

          And since our goals should be to find complete solutions, education doesn't really play much of a role in that process, because it can't be a complete solution.

        • Sure, but that does not refute Adam’s statement. You can’t educate users, except when they are already receptive.

          “The power of instruction is seldom of much efficacy, except in those happy dispositions where it is almost superfluous.” —Edward Gibbon

          • You can’t educate users, except when they are already receptive.

            I'm all for detecting failure conditions, recovering gracefully when possible, and giving clear and concise debugging instructions otherwise. Programmers should do all of those things.

            In the case of installing modules from the CPAN, users have already received some degree of instruction already. We ought to assume that we're not dealing with people who've accidentally configured the CPAN shell and somehow started installing a modu

            • I'm not sure I agree with you that users have received some instructions. Anyway, I have a story, though maybe it's not even relevant.

              At work, my office is along a busy hallway. There's a drinking fountain there, and it dispenses plastic cups. Beside the fountain there's a plastic-cup receptacle for recycling the plastic cups, and there is also a trash can. The plastic-cup receptable has four slots, and the slots are the same size as the cups. It's a clever system, designed so that the cups are neatly stac

              • I'm not sure I agree with you that users have received some instructions.

                How in the world else would a user find himself in a situation where he has started to install a distribution from a CPAN shell and that module requires an updated version of a configuration/installation distribution?

                A user must deliberately start the CPAN shell, configure the CPAN shell (unless someone has already configured it), and deliberately type the invocation to install a distribution.

                How does a user know to do this unl

                • The maximum we can assume the user understands is how to invoke the CPAN shell, and how to type "install Module".

                  Hell, in Strawberry Perl I take it one step beyond that.

                  I ship a cpan client that is already pre-configured to sensible defaults, and I add a start menu icon for "CPAN Client".

                  So whatever, they can invoke an install. That's a level of education I can accept.

                  Note, however, that this DOESN'T require any Perl knowledge yet.

                  HOWEVER, when an installation fails and somewhere in the middle of 1000 lines

                  • HOWEVER, when an installation fails and somewhere in the middle of 1000 lines of output spew is a message that says "Can't load Module::Build.pm" followed by 500 lines of random spurious errors, how on earth is someone meant to know what that means.

                    I agree. That needs fixing, preferably in an automated way.

                    The maximum we can assume the user understands is how to invoke the CPAN shell, and how to type "install Module".

                    There's the point at which the documentation needs to explain how to fix the com

  • I have several CPAN modules that use Module::Build and also use Module::Build::Passthrough to create a Makefile.PL. That is so that people can install the module any way they please, whether or not Module::Build is installed. They are all the simplest possible case - a single pure Perl module with no or minimal dependencies.

    Are you saying that going forward I will be unable to do this?
    • I'm certainly saying you SHOULDN'T use it, since it spawns a sub-CPAN client, which may well explode.

      If you have a simple module then you'd be far better off generating a compatibility Makefile.PL rather than a pass-through.

      The pass-through functionality would be best off being deprecated.
      • Huh. I just looked at one of my Build.PL scripts.

        use Module::Build;
        Module::Build->new(
            module_name => "Text::xSV",
            license => 'perl',
            create_makefile_pl => 'traditional',
        )->create_build_script;

        The Makefile.PL doesn't refer to Module::Build in any way.

        That isn't what you're deprecating, right?
        • Nope. "traditional" is quite sane.

          It's the other one, "passthrough" I think, that's conceptually broken in the same way.

    • That is so that people can install the module any way they please

      If you were actually using pass-through mode, that would not be the case. The Makefile.PL that is generated in that mode invokes Build.PL to do the work, incidentally offering to recursively install Module::Build if necessary. Therefore such distributions cannot be installed without Module::Build.

      In contrast, the traditional mode you are in fact using generates a regular Makefile.PL that invokes ExtUtils::MakeMaker as per usual, so does

  • I find it really useful, when testing a new module against several perls, to be able to simply run

    $perl Makefile.PL
    make
    make test
    and know that all the dependencies will be installed for me. I suppose I could switch to using pip, or something, but it would be more awkward. Of course, this is again using AutoInstall as a top-level CPAN(PLUS)? invocation: invoking CPAN recursively is always wrong.

    • Just replace that incantation with a single “cpan .” inside the unpacked tarball’s directory.

      • Warning: Cannot install ., don't know what it is.
        Try the command

            i /./

        to find objects with matching identifiers.

        Presumably I could fix this by upgrading CPAN (this is 1.8802), but the whole point is that with M::I as it stands the above will work on a clean install of perl, so I can see what a module is going to do in that environment.

        Also, what I gave doesn't go any further than make test. I specifically don't want this module installed (it doesn't work yet), I just want to run the tests

  • The link to Ingy's TPJ intro to Module::Install is broken. Dr Dobbs seems to have moved the TPJ articles around, breaking them out of the TPJ archive.

    http://www.drdobbs.com/web-development/184416018 [drdobbs.com]
    http://www.drdobbs.com/architect/184416018 [drdobbs.com]
    http://www.drdobbs.com/184416018 [drdobbs.com]

    The fact that they've got it archived by a number, does that mean it is likely they will move it again? Or that it is NOT likely to move again?
  • These sound like good decisions to me, Alias.

    Thanks for maintaining this module.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.