In response to the release of Perl::Shell, Shawn Moore had some fairly nasty initial feedback he chose to post to cpanrantings.
So I thought I should at least explain why I created it (in a location that won't be polluting).
Like with many areas pioneered by more advanced users, my main problem is mostly with Windows support.
Lets start with Devel::REPL, and why I didn't just use it instead.
Partly, this is my fault. For some reason, I thought Devel::REPL used Coro, so when "testing" Devel::REPL I first tried to install Coro, which won't build on Windows at all.
Of course, because I was completely mistaken about Devel::REPL I missed the fact that Devel::REPL installs just fine on Win32. I really should have known better, since Matt Trout himself uses Windows.
The only problem with DeveL::REPL is that the perl shell it provides "re.pl" doesn't work on Windows as documented, because the .pl extension is associated with who knows what.
Devel::REPL also has some other minor problems, such as using vstrings in use lines (which throws a warning), allowing incomplete statements (although a few patches from me to the PPI functionality should fix that) and odd visual behaviour when you print something without a trailing newline.
Frankly, Python did the shell usability things really really well, and I would personally would just like a clone of the way they do it.
Looking at this situation, I'll probably end up ditching Perl::Shell, and moving "perlthon" to App::Perlthon instead, since it should be a fairly lightweight wrapper around Devel::REPL, once some bugs in Devel::REPL are fixed.
As for the other alternatives suggested by Shawn Moore, the field is a bit thinner.
Shell::Perl doesn't work on Windows, so is irrelevant.
App::Perl does install, and it's iperl shell does SORT of work, but all the prompts spew weird crap to the command line. It looks like maybe it's coloured ansi gone bad.
perlconsole installs on Win32, then spews some warnings that stink of Unix biases, and doesn't support implicit multi-line statements, plus is kinda noisy.
Zoidberg I have never heard of, and would never have found in a CPAN search, and also doesn't work on Windows.
Finally, Sepia's Makefile.PL starts with the particularly inspiring comment...
To actually use this package in a useful way, you probably need to
move the Emacs Lisp files somewhere. Where will depend on your
installation.
... and then starts asking questions about optional features I have no idea about.
It installs, but at that point I actually looked at the search.cpan page for Sepia, to discover it isn't even a shell at all, but some kind of extension for an editor I don't even use. So the message makes a bit more sense, but the module is still useless to me.
So apart from Devel::REPL, they are all entirely useless from a cross-platform perspective (but obviously more useful if you don't mind being Unix-specific).
Apart from the initial mistake of misjudging Devel::REPL, it would seem there WAS room for a new shell.
I agree that with Devel::REPL, there's probably no need for another complete standalone shell. Instead, I'll probably just fix the various annoying bugs in Devel::REPL, and then rewrite "perlthon" around it instead.
Unless of course, Devel::REPL wanted to use it instead of the current re.pl script...
Speaking as the author...
First, Sepia could be used as the basis for a decent REPL, but it has been developed as part of the Emacs integration.
rlwrap perl -Mblib -MSepia -e Sepia::repl
works fairly well, but misses out on completion. I should really write a "repl" script that ties into readline at some point, but since I always have Emacs running, and don't really care for a language REPL outside an editor (you use vi?), I have little incentive to do so.
Second, you seem to have serious issues with the Makefile.PL. What is "particularly inspiring" (i.e. addSarcasm("uninspiring")) about the message? I don't know a better way to install Emacs lisp files in a sane place -- do you? (And yes, it's crazy that Emacs can't do this after all these decades...) What do you find confusing about the optional dependency messages? The Module::CoreList and Module::Info ones are not clear (and I should fix them), but the others seem self-explanatory.
Re:Sepia
Alias on 2008-08-14T07:22:15
My problems with the Makefile.PL were only because at that point I still didn't know that Sepia was an Emacs thing, and thought it was a simple REPL-like shell.
Now that I know, I'm completely fine with it.
That said, if the optional deps pass tests, it might be a good idea to just make them mandatory.
Re:Sepia
educated_foo on 2008-08-14T18:36:25
I think the deps pass tests, but PadWalker, Lexical::Persistence, and Devel::Size are all seemingly fragile XS modules (I have an open heisenbug against Devel::Size, for example). Mainly, though, I don't like forcing people to clutter their systems with modules they don't use, so I try to minimize required dependencies.
Re:Shell::Base
Alias on 2008-08-15T00:03:28
I didn't find Shell::Base in my searching.
It doesn't install on Windows, due to Term::Size failing.
I probably overreacted.
To further explain my rating, I was completely put off by (only) this section of your documentation:
Thanks to Ingy for suggesting that this module should exist.
It originally seemed to fly in the face of all the hard work people have done to make usable and featureful Perl shells. I interpreted this line as "How come nobody's written a shell that evaluates Perl before?" which would of course be ludicrous. If you had included reasons why other REPL modules didn't work for you, I would've nodded and moved on.
Hopefully you can see where I'm coming from. The documentation speaks of nothing beyond "command line interpreter in the style of Python".
I totally think there's a place for a cross-platform, lightweight REPL. Devel::REPL depends on Moose, a few MooseX modules, Lexical::Persistence, Data::Dump::Streamer.. in all probably about 30 dependencies.
I'd be happy to apply any patches you have for Devel::REPL if you do decide to contribute. We tend to do everything in plugins (to give the user complete control over what features he has). So you'd probably want to implement forcing complete statements using a plugin.
Anyway, I'm going to remove the rating, because while I think I do have a valid point, it is unfair.
On an almost but not quite completely unrelated note, Coro does at least work under cygwin. I tried it under strawberry last night and it didn't work out so well though. I'll let you know if I can get it to work.
'Cause I want Continuity on a perl on a perl on a stick stick! And who wouldn't?
Re:Coro
nothingmuch on 2008-08-18T15:44:59
You should email Marc and suggest it then, I'm sure he'll be polite and helpful;-)
