Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

  (email not shown publicly)

Journal of Alias (5735)

Wednesday December 26, 2007
08:05 PM

Vanilla and Strawberry (and Chocolate) Perl 2008 Plans

[ #35209 ]

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 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 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 Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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.

    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

    • The big win for browsers has always been automated deployment.

      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
      • I don't understand implementing a "programmer's editor". There are plenty of IDEs for Perl [] 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 []?

        • ActiveState cancelled the Visual Studio Perl version of Perl.
          • I guess this is what I mean. Why would people from the Windows world even want to use Perl, when they can use for example C# or VB? Or maybe you're not trying to win over those people.
            • The best example that I can think of is in teaching -- I met someone who was taking a Perl course, and they were using Mac's TextEdit as their editor. I tried convincing the student they'd be better off at the very least using something that did text coloring (I recommended TextWrangler, being that they were a Mac user), but they didn't make the switch.

              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
            • Why would anyone on 90% of the world's desktops want to use Perl?

              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
        • I'll add one more point to your original question.

          > 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.
  • hello adam as part of my p6doc effort and as i talked with chromatic once, im planning to write a GUI POD reader. in Wx and chrossplatform as you may suppose. i try also to kickoff with XRC to have something to talk about on next german perl workshop.
    • There already is a POD viewer in Wx, has been available for 4 years, by the wizard gmpassos [], as announced on Perlmonks []. It would be a bit of a shame to just duplicate the effort.
      • dear bart, i think it would be chame not to write it. i know this POD browser and will grep all interesting ideas he provides, but please consider 2 major obstacle it has. 1) it stayed 4years with version 0.0.1 or 0.02 and more important it uses IE4 component which makes it ein only and i wrote i want to write an crossplatform POD viewer, so that other OS user can benefit too. cheers
      • I'll look into it.
  • they will be based on WxWindows

    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: Tk vs. wx:

      FYI: There's a new 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.
      • Rule 1: It must "look like a Windows program"

        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.
  • What's the overall steps needs to make a customized version of Strawberry? Just subclass it's class, and add dists to the list?

    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.
    • I'm working on documentation for Perl::Dist as we speak, and it will include a cookbook example of making a sub-class (yes, a subclass is all you need).

      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' }