Before we kick off any further work on the Vanilla family of Perl distributions, now would probably be a good time to outline what I see as the future for project.
I've never really tried to enforce a specific "vision" for these distributions. Rather I see them as naturally evolving in a particular direction based on user requirements, under similar evolutionary pressures to other applications of their class.
So other than coding work, I see my role mainly as the "nudger in chief", keeping things pointed in the right direction, and trying to avoid having them get caught in any of the typical traps or getting distracted by shiny things that might detract from their core benefits.
So far this has worked pretty well.
Creating the initial Vanilla Perl distribution allowed the creation of a fast, cheap and low barrier-to-entry feedback loop for CPAN authors and as a consequence (one we expected) caused a great deal of work on bug-fixing and testing automation to come into existence.
CPAN support for Win32 is vastly improved as a result compared to 2 years ago.
Splitting off a dedicated distribution for users (Strawberry) while keeping our experimental "pure" version (Vanilla) made the distribution much more approachable for experienced Perl programmers without impacting on experimental and research work.
Having the Perl::Dist toolkit itself available for building distributions also satisfies the needs of People That Do Strange Things, and gives them a completely open sandbox to play in.
It reduces the need to add additional options and complexity to the "branded" distributions and this greatly improves the experience of People with straight forward needs, by preventing them having to think about issues they don't care about.
But Strawberry Perl is currently still serving double duty, and we need to split it off again, in two specific directions.
There's a clear contention between the needs of people that are experienced with Perl but not with Windows, and people that are experienced with Windows but not with Perl.
A Unix Perl hacker will look at Strawberry Perl and find it quite intuitive. It cushions the strangeness of the Windows environment by letting them behave in ways they are used to on Unix.
Hence the strawberryperl.com headline, "Complete Platform Equality".
The same cannot be said of a Windows user who is new to Perl.
They will look at a Strawberry Perl installation and feel in unfamiliar territory.
For one thing, there's no GUI interfaces to anything. There's no editor, no IDE, no anything to help them, just Notepad and a command line CPAN installer, and some links to some websites.
Rather than corrupt and bloat out Strawberry Perl with any additional stuff that Unix-focused people may not want, the clear solution here is to create a distribution specifically aimed at people who know Windows better than they know Perl, with the headline use case being the IT professional that has spent their career using Windows, but is just starting to learn Perl.
This class of user is going to want/need a richer, bloatier distribution, with GUIs for most functionality, and a large "core library" of modules available out of the box. As an environment it needs to be far more approachable.
I've previously called this concept "Chocolate Perl", and it can be loosely defined as being "Strawberry + Modules + GUI Tools".
With a stable and sub-classable Strawberry Perl released, I think now is the time to start looking at building it.
On the modules side, I want to bundle most of the major modules that people use on Windows, that are also fully cross-platform. Part of the reason for the cpan.strawberryperl.com CPAN mirror redirector is to see what Straberry users are installing, and work out what this list of modules is.
But at the very least, it will contain things like DBI, Template Toolkit, Imager, WxWindows, the Email family, LWP, WWW::Mechanize, a variety of Test:: modules, tools like Perl::Critic, and as many (good quality) Win32:: as I can reasonably jam in.
The GUI Tools will be a bit trickier, since we'll mostly have to write them from scratch.
But they will be based on WxWindows, and will most likely include things like a POD Viewer, a GUI CPAN Client, and potentially an editor such as Kephra, as well as other tools as needed or available.
In the mean time Strawberry will remain focused on the Unix Perl crowd, people that are comfortable on a command line and are happy to install modules themselves.
I expect to do a Strawberry Update release approximately quarterly, plus a release whenever we get a minor release of Perl itself (5.10.1 etc).
New features will only appear in Strawberry once they are completely stable and tested in test distributions.
The initial work on these new features (like better interaction with the environment, enabling relocation support, etc etc) will be done primarily with Vanilla Perl releases.
The next Vanilla release is already in the works, and is aimed at making the install/uninstall process a bit cleaner, with additions like removing PATH entries on uninstall, and cleaning up ALL of the installed files, including CPAN modules. This might also add the ability to "upgrade" Strawberry Perl versions without uninstalling the previous one first (although you may need to re-install CPAN modules still).
I'd also like to try and implement a "CPAN Offline" feature (basically a streamlined, zero-configuration minicpan) to deal with the common case of people using laptops that want a no-fuss "It Just Works" minicpan mirror.
In the short term however, my first goal is to get the current versions of Perl::Dist and Perl::Dist::Strawberry released, so people can start experimenting with different ideas for their own Perl distributions.
These should appear in the next few days.
The GUI Tools will be a bit trickier, since we'll mostly have to write them from scratch. But they will be based on WxWindows, and will most likely include things like a POD Viewer, a GUI CPAN Client, and potentially an editor such as Kephra, as well as other tools as needed or available.
You forgot about a debugger. If you are catering to the Windows crowd's preference for GUI development environments, you need to provide a visual debugger because from what I see of GUI environments, once testing begins, you stop living in the editor and take up residence in the debugger.
Re:Please Consider xulrunner
Aristotle on 2008-01-03T02:16:03
You are suggesting using XULRunner in a Perl distribution so it can attract more contributors who know Javascript…?
Re:Please Consider xulrunner
Alias on 2008-01-03T05:25:50
Wx is the only GUI that meets my criteria (cross-platform, native look and feel, entirely installable from CPAN).Re:Please Consider xulrunner
rjbs on 2008-01-07T15:33:47
...in other words, making Alien::XULRunner might be a first start... but probably not.:)
