FastCGi on IIS... The tale of Microsoft and my new Perl Module...
Matt S Trout
dbix-class at trout.me.uk
Fri Oct 26 03:12:33 BST 2007
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
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
> 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
> >(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
> >(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
> >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
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?
More information about the london.pm