Stepping up to the plate
Adam Kennedy has declared a contest between Dancer and Mojolicious. Seems to me like a great idea. We'll both get a chance to learn from each other, show our strengths and try to work on our exposed weaknesses.
One major issue about Mojolicious is that they decided to do everything in core (at least from perl 5.10.1), without any additional dependencies that aren't in Perl core (while, we at Dancer, try to keep the dependencies to a minimum). This has many disadvantages (reinventing the wheel, handling the same issues over and over, needing a lot of knowledge on how to implement everything) and a lot of advantages (easier deployment, easier packaging for vendors, more control). This post is about one of those advantages.
Right now, Dancer cannot participate in the challenge. The reason is since Adam uses Windows and Dancer doesn't install on Windows. It isn't that Dancer is not Windows-compatible, it's just that it uses HTTP::Server::Simple::PSGI, which uses HTTP::Server::Simple which fails a test on Windows. Thus, Dancer cannot be installed on Windows (at least with StrawberryPerl, which is what Adam - and many others - use).
Mojolicious do not need to be concerned about it, since they don't depend on it. That's a pretty big advantage. I can honestly say I'm not smart enough to be able to write everything the way people in Mojolicious did. Kudos to them!
Instead, we had to make HTTP::Server::Simple work, to be able to participate in the Kennedy Top100 V2 Challenge(tm?). HTTP::Server::Simple is written by Jesse Vincent, and I'll say this: considering how busy I assume he should be, he's very responsive. We discussed the need to fix it, but both of us couldn't fathom the exact problem with the test script that failed. Seems like the code is fine.
The entire Dancer team decided to try and fix the test. This was very encouraging since it showed how we all cared about the Windows users (which none of us were, really) being able to work with Dancer. (I can't say we don't want to win the challenge too :)
I decided to play with it over the weekend and act as if I had any chance of fixing it. After playing with it a bit, emailing Jesse a few times with several observations I've made and playing with it some more, I was actually able to fix it! Finally Dancer can be installed successfully on Windows (StrawberryPerl).
I sent a patch to Jesse and hopefully the next version of HTTP::Server::Simple will be out soon and we could step up to the plate of the challenge.
Thanks goes to Jesse (for being such a nice guy and actually answering my many emails in such a short time) and Adam (for starting the challenge, an idea I really like).
May the better framework win, may we all learn from this experience and may the code be with us!
Gots to do the bloggingz
While I was uncertain what to think about this contest (and contest in general), I think I begin to like it for it's side effects.
:-)
"One major issue..."
I think that is a good thing really. It means Mojo will install everywhere that Perl does. I don't consider that a flaw at all.
I don't consider it a flaw at all!
I didn't mean "issue" as "something that is lacking" or a "flaw", but as "topic: some situation or event that is thought about" (from Google dictionary).
Ah...I see. :-)
Mojolicious is actually dependency free right from Perl 5.8.1.
Dancer doesn't run on Windows?
Here it works great!
I am using Windows 7 x64
I installed it on top of
strawberry perl 5.12.0 - RC0.0 64bit beta 1
found here: http://strawberryperl.com/beta/
Just because you want to be dependency free that doesn't mean you have to rewrite existing software. You can just package it with your module.
I haven't looked at Mojolicious in any detail but it does seem a bit silly that they're rewriting their own HTTP/Log/JSON/HTTPD framework.
It doesn't look like HTTP::Server::Simple was actually broken on Windows. This makes me question the wisdom of requiring the tests to run during install. If some non-portable test code in one module means that none of the modules that use it can be installed on Windows, that doesn't make much practical sense.
what Perrin said -- "doesn't work" or "can't install" on windows is a too strong word. It's just a few test failing on a odd environment and is fixable, and I'm optimistic about that. I totally agree that failing tests are annoying and should be fixed, but "I can't install it because it fails tests" doesn't make much sense, instead it should be "I'll force install it for now but it's really annoying and it'd be really great that i don't have to do this."
Also, the nicest thing about Dancer supporting PSGI is that you don't even need to depend on HTTP::Server::Simple. You can install Dancer code and then Plack which is 100% green on any platforms, and use the Plack's default built-in server (HTTP::Server::PSGI) which works on win32 too.
Perhaps it was indeed too strong of a description. Criticism accepted. Thank you.
I still don't get it. On the setup I wrote above (Windows 7 x64 with an unmodified install of strawberry perl) the tests of HTTP::Server::Simple don't report any problems. Everything passes:
Running make testC:\strawberry\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0,
'inc', 'blib\lib', 'blib\arch')" t/*.t
t/00signature.t .... ok
t/00smoke.t ........ ok
# started server PID='-720'
t/01live.t ......... ok
t/02pod.t .......... ok
t/03podcoverage.t .. skipped: Test::Pod::Coverage 1.04 required for testing POD
coverage
t/04cgi.t .......... ok
All tests successful.
http://www.cpantesters.org/cpan/report/5537305
While HTTP::Server::Simple doesn't fail reliably on Windows, it does fail some of the time. And it can be a bit luck-of-the-draw if it happens to you.
I have a system that it just happens to fail on, and so does at least one of the Dancer guys when they tried.
Frankly, HTTP::Server::Simple fails spuriously on all kinds of platforms from time to time.
I absolutely agree that it would probably be a good idea for Dancer to move to Plack as it's default server instead.
Miyagawa: Part of the conditions of this competition is that I'm trying to emulate as best I can the experiences of a newbie, or at least the unwashed masses.
If we look at the core of your post "It's just a few test failing on a odd environment and is fixable, and I'm optimistic about that." you'd have to agree that while you and I can come to that decision, for a more newbie type (or someone that doesn't know Perl at all and is trying to just deploy a shrink-wrapped Dancer application) they have no ability to make the same judgement calls we do.
They can't tell it is fixible, optimistic or otherwise, and since they don't always know Perl well there's no "just" about it. And they don't necessarily know their environment is "odd", it's just their environment.
The situation for them is "It's tests failing".
How are they to make a judgement call that they should force the install, or even know they CAN force the install.
Tests that fail during install for a regular user mean that the author does not believe the code will work on that host, and not installing is preferable to installing and then failing more weirdly later in production.
So insisting on reliable installation, especially in the context of a competition, is completely reasonable.
``
''It's only a matter of time before even beginners recognize that many modules contain ridiculous tests having nothing to do with whether or not the module actually works (POD coverage and POD syntax being two of the more obviously absurd cases). Tests have at least as many bugs as modules, after all -- they're all code.
educated_foo:
If they realise this, they are by definition no longer newbies. And there are by definition always more newbies.
I think it's fair to say that requiring tests to pass before installation is not the norm for other languages and packaging systems. You don't see this sort of thing for python packages, or rpm/deb binary packages. I think running the tests on install should be encouraged but optional, and by optional I mean defaulting to off. Tests are great for people who want to contribute code, but we spend an awful lot of time fussing with them in situations where they don't really add value.
educated_foo: which is why 1) the "oslo consensus" environment variables exist, and 2) the xt/ directory is starting to step up to the plate.
Aristotle: It is a truth universally acknowledged, that a single programmer in possession of a bug-free program must be in want of a newbie...