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 11 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Please, for the love of god, don't get rid of auto_install. It's the reason Best Practical uses Module::Install instead of M::B or EU::MM.

    We use it for everything we do and it's the difference between night and day for our users. (and yes, you should read that as "the difference between usability and moving off to go use PHP instead").

    I have no problem whatsoever with "gutting and redoing the mechanism that auto_install uses to be less broken", but just getting rid of it is going to lead to a world of pain

    • Re:Noooooooooo (Score:2)

      by jesse (2531) on 2008.03.19 0:03 (#61698) Journal
      To clarify, it is very frequently the case that users are installing things like Jifty, Jifty applications, RT plugins and the like from the command line, not from within a CPAN process.

      Disabling auto_install if the user is already inside CPAN or CPANPLUS makes some sense, but hobbling users installing applications or modules directly is a really bad plan.
      • Matt reported that there were a few other things that removing auto_install broke as well (feature() for one) plus it looks to be harder to rewrite it than I initially thought, so I've already (as of a few hours ago) released a 0.70 which rolls back the auto_install deprecation (but keeps the other changes).

        This is basically to give him/you/anyone-else some breathing room to get the replacement code written (tentatively to be written in Module::Install::InstallDeps and accessible by "make installdeps").

        Any
        • What's the problem with logic of the form: "if you're running under a CPAN/CPANPLUS process, disable auto_install, but otherwise let it run"? Is there a reason the name for the option to automatically install prereqs needs to get changed and break Makefile.PL backwards compatibility? It feels sort of gratuitous to force the name change and I don't quite understand what forcing the name change wins if you're replacing the implementation with something that voids the pitfalls.
          • The logic is just fine.

            The IMPLEMENTATION of "if you're running under a CPAN/CPANPLUS process" turns out to be impossible to implement robustly, despite years of trying.

            So while it's ok to LAUNCH a CPAN shell from a Makefile.PL in principle, it's not ok to try and automatically detect which way you should go.

            The reason to change the command name is to separate out the intent of the authors who want the ABILITY to use Makefile.PL as a top-level installer vs people that want to use auto_install to do inline
      • Are you aware of the presence of cpan . (that is, cpan dot, called from the command line)?

        • No, I hadn't been aware of it. As of: cpan script version 1.9, CPAN.pm version 1.9205 it's not documented in in the manpage, either :/

          I'm not yet sure if this will solve my specific problem, though it may. But I'm known to have a big problem with backwards incompatible API breakage in CPAN modules which have been widely used or publicly available for a long time.

        • Heh, I've never thought of cpan .. It's something that I'll have to add to the documentation. :)
          • Yes, I am about to change the lengthy

                perl Makefile.PL
                make
                make test
                make install
            (and also mentioning "nmake") with just

                cpan .
            in my distribution READMEs.
            • Well, I wouldn't replace it, but put it first and then label everything else "the hard way" :)

              The trick is getting people to configure CPAN.pm so cpan works correctly. If they can't get that done (say, perhaps because they are offline or behind a firewall), they still need instructions to do it the old way.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.