FastCGi on IIS... The tale of Microsoft and my new Perl Module...

[Matt S Trout]

On Wed, Oct 24, 2007 at 07:29:23PM -0500, Ken Williams wrote:
> Matt S Trout wrote:
> >"Anything but Module::Build".
> >
> 
> It's disappointing to see a FUDdy post like this about a project so  
> many people have put work into. =(  Thanks to a Minneapolis.pm member  
> for pointing it out to me.

FUD? This is my experience of users trying to deal with M::B dists
in the wild. I used to be an avid user and fan but having been involved
in a number of projects that were using it I've now become disillusioned.

> >Module::Build is a FPITA because -
> >
> >(1) it's neither core (on 5.8) nor self-bundling ala MI, so you  
> >have no
> >guarantees at all about what the user's got
> 
> Modern versions of CPAN (Jan. 2006) and CPANPLUS (Jan. 2003) both  
> know how to deal with installing M::B properly for distributions that  
> use it.  It thus becomes no more of a burden than any other module  
> dependency.

So if I'm lucky the user will have an updated piece of another software
that works around Module::Build's model being broken.

That just moves the problem to a different module.
 
> Also it is of course a new core module in the upcoming 5.10, and  
> we're working on a new self-bundling mechanism similar to (but better  
> than, i.e. giving the user more control) M::I's mechanism, so it will  
> be even *less* of a burden than now.

That just moves the problem to a version of the runtime instead of a module.

I do look forward to the self-bundling though; that'll remove my primary
dislike.
 
> Adam Kennedy (M::I author) has also suggested creating a new  
> configure_requires flag for the META.yml which would advise CPAN and  
> CPANPLUS to install M::B (or whatever installer the author uses) even  
> earlier in the process.  We're adopting that mechanism too.

Which is nice, but again doesn't help if users don't have anything suitable
installed already.
 
> >
> >(2) it does its $VERSION etc. handling using a set of fragile regexes
> 
> We use the same approach that MakeMaker uses, could you please  
> provide a realistic test case that fails under M::B but succeeds  
> under MakeMaker?  I am not aware of any such cases at this point.

We tried to do $VERSION sharing between Catalyst.pm and Catalyst/Runtime.pm
for 5.70; EUMM dists worked fine with it, MB ones didn't.

By that point, I didn't care enough to submit a test case since I knew a vast
number of users would be running versions without any fix anyway so it was
irrelevant.
 
> >
> >(3) it changed the meaning on INSTALL_BASE in the last major  
> >release (yes,
> >that was a year ago. Unfortunately due to (1) I -still- see the  
> >problem
> >randomly popping up on a regular basis)
> 
> That was not a year ago, that was 2.5 years ago.  It debuted first in  
> a beta release because people (like you, I presume) don't like to see  
> lots of quick changes in major releases.

It's still causing problems.

And I was talking about a production release which started to cause real
sites to update.

> In any case, the whole point of install_base (which never would have  
> happened if it weren't for M::B, I might add) is to guarantee a  
> predictable install location.  That's not possible when using PREFIX  
> (see e.g. http://search.cpan.org/~mschwern/ExtUtils-MakeMaker-6.36/ 
> lib/ExtUtils/MakeMaker.pm#PREFIX_and_LIB_attribute).  And the only  
> reason we changed install_base 2.5 years ago was because Schwern  
> wanted the paths different when he added install_base support to  
> EU::MM, so we changed it so that EU::MM and M::B did things the same  
> way.

Then you should have given it a different name.

> If you're still seeing "the problem randomly popping up" I think that  
> just means you have old versions of M::B installed.  If you'd rather  
> not standardize your versions, you can use the --install_path option  
> to specify exactly where you'd like things to go.  But either way the  
> power is in your hands at this point.

Yes, the power to have old ~/ install directories silently break on a
Module::Build upgrade, and any user using instructions based on those
older versions too. I feel warm and fuzzy and empowered now.
 
> >
> >(4) it decides -at install time- what capabilities to build,  
> >requiring a
> >re-install of the same version to fix it later.
> 
> No, that was corrected in April of 2005.  auto_features are now  
> evaluated at runtime, not install time.

Ah. Yet the workaround for force re-installing it still works. Possibly
it's some sort of other fuckup then. Since I have to force it to latest
version to get behaviour I can rely on (until the next random interface
break at least) I don't find this one overly troubling me now.

A final note:

Catalyst has ported away. DBIx::Class has ported away. Most extensions to
both have ported away.

The number of users having horrible problems trying to get our software
installed has dropped significantly as a result.

There are many other projects that have shifted for similar reasons, with
similar results. I identify none because the authors of those projects can
speak up on their own behalf if they want to be accused of FUD too.

Module::Install is also hateful. I -still- love Module::Build on the author
side. But for CPAN installation it's simply not a sane option. Once you've
got the bundling sorted or in 5 years when most sites have updated to versions
of the toolchain that work around the issues, I suspect it'll be a fantastic
option. But right now it simply isn't.

echo "do 'Makefile.PL'" >Build.PL
echo '^Build.PL$' >MANIFEST.SKIP

is what I've been running after writing an M::I Makefile.PL for M::B projects,
and has been doing me very well indeed.

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/