use Perl

• Noooooooooo (Score:2)

  by jesse (2531)

  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: (Score:2)

    by jesse (2531)

    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.
    • Re: (Score:1)

      by Alias (5735)

      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
      • Re:Noooooooooo (Score:2)

        by jesse (2531) on 2008.03.19 0:47 (#61702) Journal

        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.

        Reply to This

        Parent

        • Re: (Score:1)

          by Alias (5735)

          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