Stories
Slash Boxes
Comments
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 ]

dagolden (6584)

dagolden
  (email not shown publicly)
AOL IM: xdaveg (Add Buddy, Send Message)

Journal of dagolden (6584)

Wednesday August 26, 2009
06:29 PM

Call for proposals: CPAN META Spec

The CPAN META Spec is the basis for the META.yml metadata files included in most modern CPAN distributions. Since the spec was last updated two years ago, there have been suggestions in many forums for how it could be improved in clarity or functionality, but nothing has been done.

To move from ideas to implementation, I have convened a working group of Perl/CPAN toolchain developers, maintainers, packagers and indexers -- the people responsible for the tools you use to configure, build, install or search for CPAN modules -- to review proposals, reach consensus and ultimately implement a new CPAN META Spec.

To ensure that we benefit from the best ideas in the Perl community, on behalf of this working group, I am issuing a public call for proposals.

Process

Here is the process and timeline:

  1. Add proposals to the CPAN Meta Spec Proposals page on the Perl QA Wiki. Discussion and refinement is encouraged through the discussion page on the wiki or on the cpan-workers mailing list (see below for details)
  2. The Call for Proposals will close on Oct. 1, 2009.
  3. The working group will post proposals on the cpan-workers mailing list for public discussion
  4. Public discussion will close on Nov. 1, 2009.
  5. The working group will reach consensus on proposals to adopt or reject and release a new CPAN META Spec no later than Dec. 1, 2009.

Criteria

Since the work of implementation requires volunteer effort, the working group is looking for incremental improvements rather than complete rewrites of the spec. Proposal are more likely to be adopted if they:

  • Improve clarity or resolve ambiguity
  • Are narrow in scope
  • Address specific, current deficiencies
  • Are consistent with the general style of the existing spec
  • Require minimal implementation effort

Resources

The current spec: Browse the current spec, as converted to HTML, here: http://module-build.sourceforge.net/META-spec.html.

The repository: The official spec draft file, META-spec.pod, has been moved from the Module-Build repository into its own repository on github. Please feel free to include proposed patches as part of proposals:

The wiki: Proposals will be kept on the Perl QA Wiki: http://perl-qa.hexten.net/wiki/index.php/CPAN_Meta_Spec_Proposals

The mailing list: Subscribe to cpan-workers by emailing cpan-workers-subscribe@perl.org. List archives are available at http://www.mail-archive.com/cpan-workers@perl.org/

Wednesday April 29, 2009
08:54 AM

Leaving use.perl.org for dagolden.com

Like many others, I'm giving up on use.perl.org for keeping a journal and setting up my own blog. If you follow my post here, I hope you will consider subscribing to dagolden.com to get my updates in the future.

I've accepted the Iron Man challenge, so I hope to be posting a bit more frequently.

The newest post is my summary of the 2009 QA Hackathon.

-- dagolden

Sunday February 08, 2009
07:55 PM

Module::Build/CPANPLUS yak shaving

Lately, I've decided to take on my long-standing frustration with getting CPANPLUS and CPANPLUS::Dist::Build to upgrade Module::Build. Thanks to some help from Jos Boumans, Chris "BinGOs" Williams and Eric Wilhelm, I think these hairy yaks are finally getting shaved.

  • Step 1: Module::Build 0.31_03 has just been released. It contains some workarounds that should allow existing versions of CPANPLUS::Dist::Build to upgrade Module::Build.

  • Step 2: BinGOs is working on an alpha of CPANPLUS::Dist::Build that will no longer try to use the Module::Build API directly, but will interact with Build.PL and Build through subprocesses using IPC::Cmd.[1] This will also mean bumping up the Module::Build version prerequisite, which will actually work, thanks to Step 1.

  • Step 3: After a period of testing, I hope to bump these from alphas to full releases and also roll both into bleadperl in time for 5.10.1.

If all goes well, we should finally be at a point where modules can just specify 'configure_requires' on a recent version of Module::Build and -- assuming a recent enough CPAN.pm or CPANPLUS -- things should just work.

I'm also looking into porting code from TAP::Parser::Iterator::Process into IPC::Cmd that will enable it to capture output buffers from interactive programs on Win32. This -- along with Step 2 -- will make the output from Build.PL and 'Build test' available for CPAN Testers reports on all major platforms, which is a common complaint today about CPANPLUS-based reports for modules with Build.PL

-- dagolden

[1] Why avoid the Module::Build API? The issue is that Build.PL expects to be able to create a Module::Build object from an arbitrary class. In this case of Module::Build itself, it wants to use the new version in 'lib' to build and install itself (just like ExtUtils::MakeMaker does). Or any Build.PL could use a Module::Build subclass, either on the fly or bundled in the 'inc' directory. Or it could use a replacement for a Module::Build .pm file bundled into the 'inc' directory.

In a more extreme case, some future tool could use the Module::Install trick of taking over Build.PL and generating a Build program and providing a new implementation for 'Build', 'Build test', 'Build install' and so on.

In short -- a program calling Build.PL can't make any assumptions about what happens except the creation of a 'Build' program that can be executed with various actions.

Therefore, the only safe external API that installers should use is running 'perl Build.PL' and 'Build *' actions in a separate process. The Module::Build API itself should be a private one that is only used within a Build.PL or within Module::Build subclasses.

Thursday January 08, 2009
05:35 PM

How many parsers does it take to break META.yml?

It looks like Perl 5.10.1 may include Parse::CPAN::Meta, so that CPAN and CPANPLUS will support 'configure_requires' out-of-the-box. This is a major step in improving forward compatibility of the CPAN installation toolchain.

However, it sparked a discussion on perl5-porters whether Parse::CPAN::Meta is ready to take on any META.yml on CPAN and so I used the visitcpan tool I wrote about in my last journal post to investigate.

I checked not only how Parse::CPAN::Meta handled META.yml, but also YAML::XS, YAML::Syck, YAML::Tiny and YAML.pm. Plus, I cross-checked each pair to see whether they produced the same output.

The results show that very few of the 16,000 or so distributions on CPAN have META.yml problems (most probably don't even have META.yml). But of those that do, the different YAML parsers can give subtly different output. (Click any red "-" box to see details.)

Is Parse::CPAN::Meta any worse than the others? Hard to say. Personally, I think it's "good enough" for 5.10.1 and hope any corner cases are fixed over time.

-- dagolden

Friday December 12, 2008
04:03 PM

How to look inside every CPAN distribution

Ever wonder how many CPAN distributions use Module::Build, or Module::Install? Or how common the different ways Changes, ChangeLog, Changelog, etc. show up in a distribution? Or how many distributions use a particular expression in code?

I wrote App-CPAN-Mini-Visit and the visitcpan tool to make answering such questions a lot easier.

It provides a command line tool that unpacks each distribution tarball in a CPAN::Mini repository, visits the resulting directory, and executes another program. For example, listing all distributions that contain Build.PL:

$ visitcpan --append=dist -- perl -E 'say shift if -f "Build.PL"'

AASSAD/Catalyst-Helper-Controller-Scaffold-HTML-Template-0.03.tar .gz
ABERGMAN/Alien-0.91.tar.gz
ABERGMAN/File-Find-Random-0.5.tar.gz
ABERGMAN/ SVL-0.29.tar.gz
...

Clearly, if I were running frequent analyses, I might just use CPAN::Mini::Extract and keep all the tarballs extracted, but since I only occasionally have questions like this, I'm willing to make the space/time tradeoff.

Oh, and to answer that first question, here's how many distributions use each style of installer:

$ visitcpan -- perl -E 'if (-f "inc/Module/Install.pm") { say "MI" } elsif (-f "Build.PL") { say "MB" } elsif (-f "Makefile.PL") { say "EUMM" }' | perl -E 'while (<>) { chomp; $cnt{$_}++ } say "$_: $cnt{$_}" for keys %cnt'

MI: 2306
MB: 2675
EUMM: 11781

Looks like Module::Install has almost caught up to Module::Build. Impressive!

--dagolden

Tuesday December 09, 2008
09:37 AM

Putting CPAN modules on github

I saw in Ovid's post about App::Prove::History that he's hosting it on Github.

I've recently started mirroring my git repositories to Github as well. It has some nice eye candy and tracking tools.

One thing that made it easy to migrate was brian d foy's github-creator package, which is a command-line tool to create a new repository on Github. You just run it from a distribution directory and it figures out a name and so on.

It's not a module (yet), so installing with CPAN requires an explicit distribution name:

cpan> install BDFOY/github_creator-0.13.tar.gz

If you're thinking of putting your CPAN modules on github, definitely try it out.

-- dagolden

Thursday December 04, 2008
10:36 PM

Hey Perl Advent, ToolSet gets even better!

I was tickled to find my ToolSet module featured in the 2008 Perl Advent Calendar.

However, in response to the comment that ToolSet didn't support pragmas like "no indirect", I decided it was time for a feature upgrade. Now that Perl 5.10 allows for user pragmas, ToolSet needed more general pragma support.

So ToolSet 0.99 has a new API for pragmas:

# My/Tools.pm
package My::Tools;
use base 'ToolSet';

ToolSet->use_pragma( 'strict' );
ToolSet->use_pragma( 'warnings' );
ToolSet->no_pragma( 'indirect' );

1;

This should work with any simple pragma that uses $^H or %^H without other side-effects during import().

Happy holidays!

-- dagolden

Thursday November 20, 2008
10:46 PM

Fun with Perl: rdesktop launcher

I've started experimenting with using rdesktop to remotely access my (Windows) laptop from my Ubuntu desktop. The annoying part was figuring out what DHCP address was assigned to the laptop each time.

Then, of course, I realized this was a job for Perl! (Plus some system tools)

So I wrote a "laptop-launcher" program and here's what it does:

  • run 'nmap' to scan for hosts with open remote desktop ports
  • parse the nmap output to map MAC addresses to IP addresses (thank you Regexp::Common qw/net/)
  • run 'rdesktop' with the IP address corresponding to my laptop's MAC address

Just a couple minutes work and now launching a remote desktop session to my laptop is a snap.

Thank you, Perl!

-- dagolden

Thursday November 06, 2008
10:05 PM

ToolSet yak shaving adds Perl 5.10 features

As often happens, I can't remember the exact original need that started the latest round of yak shaving. I think I was working on a one-liner to prototype a test program for some small program I was writing.

In any case, I was annoyed that my XDG ToolSet module I use for one-liners didn't give me Perl 5.10 features, but adding them required a new ToolSet release.

So now "perl -MXDG -e ... " gives me strict, warnings, some of Carp, DDS, Path::Class, File::Spec, Scalar::Util and either all of the Perl 5.10 features or else at least Perl6::Say.

If anyone else finds this useful, here's the code, or clone it from git and adapt as you see fit.

package XDG;

our $VERSION = '0.05';

use base 'ToolSet';

ToolSet->use_pragma( 'strict' );
ToolSet->use_pragma( 'warnings' );

ToolSet->export(
    'Carp' => 'carp croak confess',
    'Data::Dump::Streamer' => 'Dump',
    'File::Spec' => undef,
    'Path::Class' => 'file dir',
    'Scalar::Util' => 'refaddr reftype blessed',
);

if ( $] >= 5.010 ) {
  ToolSet->use_pragma( 'feature', ':5.10' );
}
else {
  ToolSet->export( 'Perl6::Say' => 'say' );
}

1;

Tuesday October 07, 2008
11:21 AM

Hello World -- family style

$self->wife->spawn("Jeremy William Golden");

Born 1:16 AM on Oct 7, 2008. 9 pounds, 10.5 ounces. Photo .

-- dagolden