Perl 5 Porters Mailing List Summary: April 4th-10th

Hey everyone,

Following is the p5p (Perl 5 Porters) mailing list summary for the past week.

Enjoy!

Dependency phases in CPAN distribution metadata

In the previous article in this series we gave a general introduction to the distribution metadata which is included in releases as files META.json and/or META.yml. In this article I'll drill into more detail at one critical component of a distribution's metadata: dependencies, also known as prerequisites (usually shortened to "prereqs"). This is how you specify other CPAN modules that your distribution depends on.

This post is brought to you by Booking.com, a platinum sponsor for the Perl Toolchain Summit. Booking.com is one of the largest Perl shops in the world, and so depends heavily on the toolchain. Thank you to Booking.com for supporting the summit.

Dist::Zilla @Starter - Revision 2

I recently released revision 2 of the [@Starter] plugin bundle for Dist::Zilla. This revision brings small improvements to the default behavior, as well as the option to set a different installer plugin. In order to use the new revision, you must set the option "revision = 2" when using the bundle.

Revision 2 uses [Pod2Readme] instead of [ReadmeAnyFromPod] to generate the text README file. [ReadmeAnyFromPod] is a great and flexible plugin, but [Pod2Readme] is much simpler for the specific purpose of generating a text README. For any additional README files in other formats, I still recommend using [ReadmeAnyFromPod].

This revision also sets the option "inherit_version" in [MetaProvides::Package] to 0 by default. This makes no difference if your distribution contains uniform module versions, or for modules which have no version (they are still marked as having the distribution version unless you set "inherit_missing" to 0 as well), but if you have modules with different versions hardcoded, this will reflect that in the "provides" metadata.

Virtual Spring Cleaning Prelude: What I did, and what hasn't happened so far

While trying to get some more of my modules ready for release, I've been doing drive-by patches to CPAN modules that I used for various reasons. While I'm not exactly enthused about throwing a patch with a testcase over the fence, I think it's still far better to have the problem and solution in some bug tracker somewhere than having it only on my hard drive.

Better SQL tracing with DBIx::Class

I've been trying to track down some SQL issues with Tau Station and to be honest, I've never been terribly happy with the output from the DBIx::Class DBIC_TRACE or the DBI DBI_TRACE. So I have something better.

Good code style of DBIx::Custom at 2017

DBIx::Custom is good DBI wrapper to insert, update, delete, select easily and clean.

I introduce good code style of DBIx::Custom at 2017.

Connect


  my $dbi = DBIx::Custom->connect("dbi:mysql:database=dbname", 'ken', '! LFKD% $&');

Create model

It is good to create model.


  $dbi->create_model('book'); 

Execute SQL

Because model is used, insert, update, delete, select is very clean.


  # Insert
  $dbi->model('book')->insert({title => 'Perl', author => 'Ken'});
  
  # Update
  $dbi->model('book')->update(
    {title => 'Perl', author => 'Ken'},
    where => {id => 5}
  );
  
  # Delete
  $dbi->model('book')->delete(where => {author => 'Ken'});
  
  # Select
  my $result = $dbi->model('book')->select(
    ['title', 'author'],
    where => {author => 'Ken'}
  );
  
  my $rows = $result->all;

model + join

You can set join clause to model. You can get all column easily.


  $dbi->create_model(
    'book',
    join => ['left join author on book.author = author.row_id']
  ); 

  # Select
  my $result = $dbi->model('book')->select(
    [
      {book => '*'},
      {author => '*'}
    ],
    where => {'author.name' => 'kimoto'}
  );

In SQL, join clause is very bored. If you use DBIx::Custom, you can get all columns very easily. This
is the following SQL.


You won't believe this one quick Perl 6 optimization hack!

Now that I've alienated half the crowd, here's the scoop. Perl6::Parser has a fairly extensive test suite, which I run on my laptop inside an Ubuntu 14.04 VM - it's the latest version I can find that supports seamless integration, though I'm considering completely dumping the GUI and going with just a few SSH connections.

But enough of that. Baseline Rakudo Perl 6 currently runs the Perl6::Parser test suite in 0.61s usr, 0.07s sys + 80s cusr time, 90 wallclock seconds, which is rather amazing considering how extensive and invasive the test suite is. After this one simple change, that time dropped from 90 wallclock seconds to 70 wallclock seconds.

If you look at Perl6::Parser::Factory at this version, you'll see a 'role Matchable', which is public and shouldn't be.

Integrating alienfile

Last week I introduced the alienfile recipe system and we wrote a simple alienfile that provides the tool xz and the library liblzma. I also showed how to test it using App::af. Today we are going to take that alienfile and integrate it into a fully functional Alien distribution.

The main motiviation for alienfile + Alien::Build was to separate the alien detection and installer code from the perl installer code. (In fact your alienfile is fully usable without any Perl installer at all; you can use your alienfile from a Perl script or Perl module using Alien::Build directly).

For our Alien, we will be creating Alien-xz, and we will use Alien::Build::MM to provide the thin layer of functionality needed between ExtUtils::MakeMaker (EUMM) and Alien::Build. This is what our Makefile.PL should look like:

About blogs.perl.org

blogs.perl.org is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is hosted by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.