All the Perl that's Practical to Extract and Report
use Perl Log In
Alias (5735)
Vanilla and Strawberry (and Chocolate) Perl 2008 Plans
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.
so frantically :-)
-- Jarkko Hietaniemi
Before you lockin that GUI... (Score:1)
Um...why ? or rather, why not the GUI toolkit that is/has supplanted all others, namely, the web browser ? Its 2008. As of about mid-2006, its become increasingly clear that, "if it doesn't run in a browser, it don't mean sh*t."
At the risk of sounding like a buzzword bingo caller, it would be a shame to
Re: (Score:1)
If you want to run everything locally, there's still advantages to doing things in a GUI. Introducing a client server model and the overheads of doing things in Javascript for a process that is inherently local has it's own downsides.
That said, it may well be that some of the client side apps ARE done in HTML/Javascript.
The POD viewer is one example of an application that would be ideal to do browser-based. It's document focus aligns well with th
Re: (Score:1)
I don't understand implementing a "programmer's editor". There are plenty of IDEs for Perl [perl.org] already, aren't there?
It's a good idea to make things work better on Windows, though. Languages like Python or Ruby seem to have already dealt with this better than Perl has.
But what kind of motivation would a Windows programmer have to use Chocolate Perl instead of, say, Visual Studio [microsoft.com]?
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
I'd assume that making it easier for a non-programmer to pick up and program in Perl is a good thing, especially if it results in schools being more willing
Re: (Score:1)
Because they are forced to use Windows by corporate policy.
Because of the CPAN... because there's so much depth to the pre-written code out there, and assembling components in Perl is SO much easier compared to Windows languages once you need to do anything even remotely esoteric or interesting.
Because Windows + Mac + Linux == cross-platform, which is a hugely desirable feature.
Because developers can write GUI business tools on Linux (which th
Re: (Score:1)
> I don't understand implementing a "programmer's editor". There are plenty of IDEs for Perl already, aren't there?
Yes, but they all suck.
POD Viewer (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
Toolkit shoot-out? (Score:1)
I don't anything about the relative merits of the different GUI toolkits that do Windows, but I do know that I was very impressed by the native look'n'feel of the PPM front-end that appeared in recent Activestate distributions.
I think that uses Tkx. The other thing I have heard is that the Wx documentation is pretty poor, and thus the barrier to entry is high.
My point is that whatever toolkit is used, it must be well documented and have lots of examples. I'd really lik
Re: (Score:1)
RE: Tk vs. wx:
FYI: There's a new Tcl/Tk [www.tcl.tk] release that purports to have platform-specific theming. While it probably won't be available from Perl/Tk anytime soon, the other Tk based toolkits may be able to leverage it quickly.Re: (Score:1)
Rule 2: It must be installable via the CPAN.
Rule 3: It must be cross platform
From that set of constraints, only WxWindows meets all three.
Re: (Score:1)
Quickest Path to Subclass (Score:1)
I'd like to have a go at replacing my CatInABox zipped dist folder with a real Perl::Dist that I can rebuild and keep updated that contains a complete running Catalyst install with all the trimmings.
Re: (Score:1)
But completely off the top of my head (and probably a bit buggy) it would look something like this.
package Perl::Dist::CatInABox;
use strict;
use base 'Perl::Dist::Strawberry';
sub app_name { 'Catalyst In a Box' }
sub app_ver_name { 'Catalyst In a Box December 2007' }
sub app_publisher { 'Catalyst' }
Re: (Score:1)