This month (March, but I forget the exact date) we celebrate the 1st anniversary of Vanilla Perl, and I'd like to thank all the Windows Heroes from irc.perl.org #win32, win32.perl.org and elsewhere that have put so much effort over the past year into helping make Perl on Windows suck less, as well as the many CPAN authors that have let us fix their modules, or fixed them for us.
Looking back how things have progressed, you can see a definite pattern forming.
Phase 1 - Creation of initial Vanilla Perl distro
Phase 2 - Porting and repair of the CPAN toolchain
Phase 3 - Creation of Perl::Dist and Strawberry Perl
Phase 4 - Porting and repair of the most popular CPAN modules
As you can see we've sort of swung back and forth twice now from working on the core distribution process itself, to working on modules and supporting issues.
While the porting and repair work on CPAN modules is likely to be an ongoing thing, I think I'd be safe in saying that most of the low-hanging fruit is gone now.
Almost all the basics of everyday life now work just fine on Windows, I'm happy to say.
There two situations left in which we have recurring problems. Both of these could be resolved by the people involved fairly easily, so I'm going to brand these people Windows Villains. :)
The first category are authors that, once we get their modules working on Windows, make major changes without doing dev releases to allow CPAN Testing to do it's job, and regress the entire platform into brokenness again.
The two big standouts here are Template Toolkit and POE, which both drift back and forth between working and breaking.
It's not necessarily the author's fault for breaking them, they simply don't have the time to check, or don't have access to Win32, or care. But literally hundreds of other modules depend on these two, so for the sake of a dev release or two we have hundreds of modules being broken for months at a time between major releases.
The second category are similar. We've been producing patches and fixes for a number of modules, but the authors either haven't noticed or haven't had to time apply them. If the author has disappeared altogether, it's actually EASIER to fix them, because we just take those modules over.
If you own one of these modules, we'd really appreciate commit access or letting us have co-maint. We promise not to muck around with your code except for the compatibility changes, we've gotten quite good at it over the last year.
From the Win32 Problem Modules status page, our current list of Windows Villains for outstanding patches is Crypt::DSA, Devel::ebug, File::chdir, File::Tail, Module::Compile::Simple, Net::DNS, ppt, Sys::Hostname::FQDN, Test::HTTP::Server::Simple, WWW::Mechanize::Pluggable and WWW::Mechanize::Sleepy.
Please guys, if you could all move slightly to the left and just let us (well, chorny and tsee mostly) get past and fix your modules for you, we'd really appreciate it. :)
In any case, when it comes to CPAN modules I'm pretty happy now to draw a line under this work and call it "finished (mostly)".
Which leads us to the next series of problems to solve, and a new 3rd generation distribution.
Firstly, we need to get from an .exe installer to an .msi installer. I don't ENTIRELY understand all the advantages of this, but I'm told it enables cool things (for Windows Admins at least) like pushing out applications to entire companies via Active Directory.
The most promising progress on this problem is happening around a module in my repository called Win32::Wix. WiX (Windows Installer XML) is an XML dialect that when combined with a set of simple console .exe tools can be used to generate .msi installers.
I wrote up an initial skeleton several months ago (taking an existing XML file and wrapping the WiX applications) but didn't really have the time to go further. metatrontech++ has recently picked up the module and is improving it to actually generate the XML files as well.
Once this is all working, hopefully we can merge it into Perl::Dist somehow and let you generate EITHER .exe installers or .msi installers as you wish (I'm fairly sure David would like to do some general refactoring on Perl::Dist as well).
As an added bonus, I'm informed that the WiX .exe applications I bundled into Win32::Wix also work out of the box with mono, so we also have the prospect of potentially being able to generate .msi installers on *nix. Apart from being fairly funny, this also makes for a cleaner bootstrapping from the main operating system used by Perl coders to Windows.
There's also some changes pending to the MinGW setup to make them work better/properly on Vista, and it's probably about time we worked out how to force man pages to not be built (saving a bunch of disk space).
Driving these changes is the emerging demand from companies (I've had two job offers in the last couple of weeks) to take existing Perl applications made for Unix and be able to deliver them to customers that want to run them on Windows using Vanilla Perl as a (largely invisible) platform.
They like the idea of a fully automated and Open Source tool they can just throw their application at in the form of a CPAN-like distribution or something similar, twiddle with a few things, tick a few boxes, and it will work out the details and spit out an .msi installer.
They can then send that to their customers, who can push it out via Active Directory to their whole company. None of the customers even need to know the application is in Perl, it should all Just Work on Unix, Mac and Win32.
This means more income for Perl development companies, and more jobs for Perl coders. Which is always a positive thing.
Also driving this need for a new Vanilla release cycle is the upcoming Perl 5.10.0 release. Because the distro build process is now totally automated (thanks to David Golden) we hope to release an official production Strawberry Perl 5.10.0 on the same day as the official Perl 5.10.0 source release.
And after all THAT is done, maybe we'll finally get enough breathing room to start looking at doing Chocolate Perl and I can finally get my GUI CPAN client. :)
Re:TT
Alias on 2007-03-20T12:59:31
No, I made two release of TT that fixed Win32 and one particular mac issue.
Then Andy came back, merged my changes, un-disabled the test that was failing, didn't check that it actually worked, and now it's broken on Win32 again.
I agree that Win32 isn't the ONLY problem with TT, but it's caused by the same problem. Andy isn't personally able to work on TT, but won't/can't/forgets to compensate for his own lack of time.
There's reason people get co-maintainer and CVS commit rights.
Re:Kwalitee: Builds on Windows?
Aristotle on 2007-03-20T11:31:26
Only as optional metrics please. I doubt IO::SendFile or IO::Epoll are ever going to work on Windows, no matter how much effort you put into it…
Re:Kwalitee: Builds on Windows?
link on 2007-03-20T14:54:08
But wouldn't they be better kwalitee modules if they did. Maybe not better quality...Re:Kwalitee: Builds on Windows?
jjore on 2007-03-20T15:50:10
So? There's nothing wrong with having unattainable kwalitee. Heck, your kwalitee could drop if the standard tests change. That's a good thing - hopefully as tests progressed more classes of bugs are tested for and that feeds into finding distributions which previously weren't tested for that.
I figure it's normal for your "kwalitee" metric to decay over time just as a side effect of what kwalitee means changes while a distribution doesn't.Re:Kwalitee: Builds on Windows?
jjore on 2007-03-20T15:53:43
Incidentally... I'd prefer if Test::Kwalitee were configurable on a distribution level so all the author tests could just removed from the distribution. I've recently started removing all the redundant author stuff from my distributions because I think they are either redundant code (all the pod stuff) or are harmful (all the signature stuff).Re:Kwalitee: Builds on Windows?
Alias on 2007-03-21T00:00:11
I keep the POD tests, but having signature tests is utterly pointless.
Re:Kwalitee: Builds on Windows?
Alias on 2007-03-20T13:02:11
I'd rather see a metric for "No CPAN Testers failures".
Modules should either PASS or return a NA.
Adam K
Re:RT
Alias on 2007-03-20T15:37:56
Dunno, if there's something you care about, bug them again (like I'm doing here):)
