Some sample text, this will be deleted later.

This is only of interest to Mac users who link their Perl against MacPorts code, but if you are such a person, you may find this useful.

This morning I found that Perl code that used LWP::Protocol::https was failing, but only when run by the test harness.

After some flailing around I managed to track this to the fact that I had just updated MacPorts, and taken openssl from 1.0.2f_0 to 1.0.2g_0. I still do not know the precise cause of the failure, but it was exposed by the fact that the test harness (whether ExtUtils::MakeMaker or Module::Build) set PERL_DL_NONLAZY=1.

Downgrading to the old openssl did not fix the problem of course, but made the symptoms go away. The short version of the procedure is

$ sudo port activate openssl @1.0.2f_0

For details on downgrading a port, see https://trac.macports.org/wiki/howto/InstallingOlderPort

In my last YAML post I said libsyck is not maintained anymore. I had a look, and this is wrong. Even if _why does not work on it anymore, (he came back btw recently), it is maintained and made some progress in libsyck, which is not reflected in the YAML::Syck perl part.

It is a mess, I admit, but easier fixable than the YAML::XS mess. So I took libsyck upstream, which is at 0.70, and merged it with our changes which are at 0.61. Our perl-specific changes are a complete mess, so I cleaned that up to be acceptable upstream into a new 0.71.

merge back various changes from upstream (my own WIP version 0.71)

Personally I'd prefer YAML over JSON for local config data anytime. Even if JSON is secure by default, and YAML is insecure. YAML is readable and writable. It's better than .ini, .json and .xml.

But Houston we have a problem. For a long time. I'll fix it.

We have the unique advantage that the spec author and maintainer is from the perl world, Ingy, and maintains the two standard libraries YAML, the PP (pure perl) variant, and YAML::XS, the fast XS variant, based on LibYAML.

This would be an advantage if those two libraries would agree on their interpretation and implementation of the specs. They do not.

Historically the YAML library is used as the default reader for CPAN .yml preferences and a fork of YAML::Tiny, CPAN::Meta::YAML which is in core is used to read and write the package META.yml files.

Too long/didn't read: Don't use Test::WWW::Mechanize::PSGI or similar, use LWP::Protocol::PSGI. I wish I'd found out about this module when it was first released in 2011 rather than in 2015. Which is why this article is here. LWP::Protocol::PSGI is great work and needs to be more widely known.

Since we moved away from monolithic web applications deeply embedded into the web server via the web framework movement and PSGI, now around a decade ago, a common way of testing things has been with modules like Catalyst::Test, Test::WWW::Mechanize::PSGI, Dancer2::Test and similar. These work by mocking the http request and response layers, with the mocked layers talking to an object or a subroutine reference rather than a web server. Which is fine, except, say you want to test both against your application code and your web server using the same test suite. You end up having to do fairly nasty things to decide if you are dealing with a mocked http request/response layer talking to a coderef, or a real one talking to a web server.

Fortunately LWP::Protocol::PSGI eliminates this entire problem.

TL;DR - if you have an Alien::Base based Alien module, please update configure_requires so that it depends on Alien::Base::ModuleBuild instead of Alien::Base, and (this part is key) make a release.

This is technically more correct, and it will also future proof your module in the event that Alien::Base::ModuleBuild gets spun off from the rest of Alien::Base. There are a number of motivations making such a move. Please join us on GitHub or the #native IRC channel if are interested in working on the next generation of of Alien::Base.

continuous integration using sparrow tool chain

Sparrow is a tool to automate testing infrastructure. Automated testing is essential part of continuous integration processes as it provides fast feedback on cases when something goes wrong.

Consider simple example of how sparrow could be used to build up some basic parts of your infrastructure.

web application development

We have a simple Dancer2 application we are going to deploy on development environment:

app.psgi

#!/usr/bin/env perl
use Dancer2;

get '/' => sub {
    "Hello World!"
};

dance;

Let's keep source code at git repository:

git init
git add app.psgi
git commit -a -m 'my web application'

git remote add origin https://github.com/melezhik/webapp.git
git push -u origin master

development server

We are going to deploy application on dedicated server used for development environment:

ssh dev.server
git clone https://github.com/melezhik/webapp.git
cd webapp
cpanm Dancer2
plackup

Hey everyone,

I apologize for skipping last week. Following is the p5p (Perl 5 Porters) mailing list summary for the past two weeks. Enjoy!