Curtis Jewell's Perl stuff

There really IS more than one way to do it, even on Windows!

Entries tagged with future

I do have plans for the October 2009 version of Strawberry Perl, and for releases of other perl distributions based on it.

And yes, there will be others.

The Enlightened Perl people would not mind if I made a distribution based on Task::Kensho - I'm told to call it Satori Perl. (I will note that it will stay beta for while - I'm pretty conservative, and I'd have to check the modules used heavily, as I know that there's one problem module already. )

The Padre people want a standalone version (as mentioned in the previous entry) with Padre installed, with all its prerequisites.

And that's just the two I know about and that would go up to the CPAN.

Somebody on IRC wanted a "Strawberry + Perl 6" (Actually "Padre + the Perl 6 plugin") - that's still too much in flux and still quite a bit unpackageable (it was tested in January and it had a LOT of hardcoding in the build process) to want to try and aim for that for October. Plus the fact that you have to pull svn builds of Parrot to build Rakudo. MAYBE January 2010. MAYBE. I have adequate tuits, but not overabundant tuits.

So without further adieu, here's the list.

Anybody wanting to add to it, please comment, and I might just edit the entry.

One of the three top priorities for October is to make creating perl distributions for Windows even easier. How I intend to do that - I can't mention here just yet. I'm still mulling it over and talking to others about it. But come October, you may very well be able to install multiple "Strawberry-subclass" distributions without problems, and/or be able to include Strawberry easily in other Windows Installer files.

Top priority #2 is what I'm calling the "vendorperl" branch - the ability to put the modules installed by a perl distribution in a 'vendor' directory, as described in schwern's description of the difference between core/perl, vendor, and site.

Top priority #3: Making Strawberry relocatable, at least on a "drive" level.

Other capabilities and things that will probably be included are:

A script to allow easier use of the local::lib module by non-administrators (the .msi does require administrator access to install)

The installer will delete duplicate PATH entries from previous installations of Strawberry Perl.

Detection of other perl installs at install time.

WWW::Mechanize. (not neccessarily including it in Strawberry, but making sure it installs seamlessly. And it IS going into Satori.) Anybody who's tried to install it on Win32 knows what I mean. It's a FAQ. HTTP::Server::Simple needs to just work on Strawberry, at least, and then Mechanize will be easy.

Win32::Process and 5.8.9. For some reason, this combination is just fine in a base Perl::Dist::WiX, but Perl::Dist::Strawberry spits it back up pre-chewed. (it doesn't pass "dmake".)

Giving the building process more antlers than it already has. (Currently File::List::Object is the only part of the build process that has antlers. I'd like to get rid of the dependency on Object::InsideOut - it's lots slower creating 20000+ objects than Moose would be.)*

Factoring out the code backing the release tests into their own module, like I did with File::List::Object earlier.

There are a fewissues with Portable that I'll see if I (or others) can take a swing at somehow.

I'd like to make BioPerl installable on Strawberry without too much pain.

Also, the Math::Pari installed on 5.8.9 is a 5.10.0 par. Oops. Teeth. (channeling the Men in Black.) NOW they tell me. Done.

* I have to admit, my ideas on this have evolved. At first, all of Perl::Dist::WiX::* used Object::Tiny as a base class, because the original code from Perl::Dist::Inno I based it on did. At about March or April, I was running into problems with multiple inheritance and overlapping accessors with that, so I switched to Object::InsideOut for most packages at that point, because I didn't know Moose at all. Now I'm seeing the problems with OIO (speed, Storability - can't use checkpoints without it) and am wanting to switch to Moose. I'll switch over slowly between late July and late September, package by package.