use Perl

Since the initial release of CPAN::Reporter, one of the big missing features was sending CPAN Testers reports for *.PL and make/Build stages. A while ago, I added that capability in the CPAN::Reporter and CPAN development series.

With the new, stable release of CPAN 1.92, CPAN::Reporter is very close to its 1.00 release. I've just bumped the CPAN prerequisite to match and put out CPAN::Reporter 0.99_12. I consider this a release candidate for 1.00.

If you're already using a development version of CPAN::Reporter, please upgrade to the latest to help shake out any last blockers. If you aren't using a development version of CPAN::Reporter and would like to try it, it should install easily from the CPAN shell (and will upgrade CPAN for you if necessary).

cpan> install DAGOLDEN/CPAN-Reporter-0.99_12.tar.gz
...
cpan> reload cpan

Thank you very much to everyone that has contributed suggestions and bug reports along the way.

-- David

References:

• CPAN::Reporter 0.99_12 (Changes)
• CPAN 1.92

With CPAN version 1.91_53 and CPAN::Reporter version 0.99_02, CPAN will now report to CPAN::Testers any failures during Makefile.PL (Build.PL) or make (Build).

Ironically, this pair now needs some good-old-fashioned manual testing. Please consider installing them and then testing some modules that you've seen fail to build on your system.

cpan> install ANDK/CPAN-1.91_53.tar.gz

cpan> install DAGOLDEN/CPAN-Reporter-0.99_02.tar.gz

cpan> reload cpan

Then test some module that fails to even make and see if the failure report made it to CPAN Testers.

Thank you!

Soon, all the recent use.perl journal posts will just be links to someone's Technorati Profile.

I've just released Sub::Uplevel 0.15_01. It includes Schwern's patch to localize the CORE::GLOBAL::caller override to just the uplevel call as well as my own additions to work with any existing caller override from within the uplevel call.

This should help it play nice with things like Contextual::Return or Hook::LexWrap that also play games with CORE::GLOBAL::caller.

In particular, since Test::Exception uses Sub::Uplevel, it should be safe to use Test::Exception with code that happens to use one of those other modules.

If you are in that situation, please give it a try and let me know how it works for you.

CPAN::Reporter has had over 20 releases since I first announced it here on August 26. Now anyone with an up-to-date CPAN.pm can contribute to CPAN Testers -- no smoke server needed.

Some of the major developments since August:

• Full CPAN.pm support since version 1.88; CPAN::Reporter added to Bundle::CPANxxl
• Added interactive configuration direct from CPAN.pm with: 'o conf init test_report'
• Added customization of action prompt defaults based on the test report grade. E.g., CC author on FAIL, but not otherwise
• Distributions that fail tests but are missing prerequisites are marked as NA instead of FAIL
• Test report includes prerequisite versions, environment variables, special Perl variables, and installed versions of the toolchain (e.g. ExtUtils::MakeMaker)
• Added support for old style "test.pl" files

Becoming a CPAN Tester with CPAN::Reporter is easy. From the CPAN shell prompt:

  cpan> install CPAN::Reporter
  cpan> reload cpan
  cpan> o conf init test_report
  cpan> o conf commit

Future development work on CPAN::Reporter will include better handling for interrupted tests and better integration with CPAN.pm to be able to report failures in Makefile.PL and "make" even before tests are run.

Come be a CPAN Tester today!

I'm putting together a presentation on Vanilla/Strawberry Perl for Perl Seminar NY

I'd love to include some real-world examples of how people are using it.

As of this morning, there have been 1500 downloads of various Vanilla/Strawbeery releases since my YAPC 2006 hackathon release in July. If you're one of those, please post a comment or send me an email with a couple lines about your experience.

Thanks!

This post was orginally made as Portable Alien Library System on win32.perl.org. It is reposted here for wider commentary. Some additional design details, existing commentary and references can be found on that page.

Synopsis

• Modules using "libfoo" list Alien::Foo as dependency
• Alien::Foo namespace used to manage external libraries
• Alien library files contained in the corresponding auto directory (auto/Alien/Foo)
• Alien modules provide an API for CC flags in Makefile.PL/Build.PL
• Alien modules verify library availability (e.g. in platform or Alien standard directories)
• Alien modules responsible for installing binary library files when necessary
• Alien modules support binary package download from a repository
• Alien modules support source compilation or binary re-packaging to the binary package format used for installation

Introduction

The Vanilla Perl Project provides a Win32 Perl and bundled compiler to build Perl modules from CPAN rather than relying on binary module package systems like PPM. Early feedback on the project demonstrate the many popular Perl modules that have dependencies on external libraries -- ones often assumed to exist on a Unix-based operating system.

This document describes the Portable Alien Library System (PALS) -- a framework for external library dependency specification and resolution. While its inspiration is drawn from Win32, its design is intended to provide benefits to module authors and users on all platforms.

Requirements

This list of functional objectives is adapted from the original Alien module and commentary in External Library Handling at win32.perl.org.

Dependency specification

The solution must provide a way for Perl module authors to specify a dependency on an external library. An important consideration is how a solution integrates with or diverges from existing CPAN methods and tools.

Library detection

Libraries may be pre-installed in well known locations (e.g. "/lib") or may be installed ad hoc. The solution will need to detect if a library (and associated headers) are available and identify the associated paths.

Library configuration

Given the wide variety of locations for libraries, the solution needs to provide an abstraction layer to other tools that ensures proper configuration. Examples include:

• Makefile.PL: compiler flags, including library and header paths
• Shared/dynamic library loading: libraries in non-standard locations may need changes to environment settings such as PATH or LD_LIBRARY_PATH to ensure libraries are found at runtime
• Other metadata: library metadata, such as version, may be required to manage dependencies

Binary library package generation

External library compilation from source can be substantially more time-consuming than typical XS compilation for Perl modules. Providing binaries of external libraries (whenever possible) from an online repository will provide a more user-friendly experience.

Binary library package installation

Whether compiled from source or downloaded as a binary, external modules will need to be installed such that they may be located later for library detection and configuration. The solution will need to address whether this should be platform independent or platform specific.

Design criteria

Portable

External library support is a potential problem all platforms -- not just Win32 -- and developers will be more inclined to use the solution to specify external dependencies if it addresses dependency problems portably. The solution should provide a standard interface for module developers and module users that abstracts platform and compiler details.

Modular

Library packagers may not wish to take on responsibility for creating a solution for all platforms or all compilers or may lack the necessary know-how. The solution should modularize functionality wherever possible to allow individual library packagers to work on separate parts of the solution for platforms of interest.

User-friendly

The solution should degrade gently. If library support is not available for a particular platform or compiler, the solution should fail cleanly with an explanation of the dependency problem prior to generating XS compilation failures during linking.

Maintainable

Ongoing availability or upgrades of an external library should not depend on a single individual or on tacit, undocumented packaging know-how. As with Perl::Dist::*, the published solution should contain an automated process to convert an external library from source (or binary package) to the binary package format used by the solution.

Design overview and commentary

The following design description will make more sense if you examine the Alien Ecosystem diagram.

Dependency specification

CPAN modules with external library dependencies will specify a module dependency on a corresponding Alien:: module, e.g. Alien::Foo for the "libfoo" module. Dependency management can thus be handled within the existing system using ExtUtils::MakeMaker, Module::Build or Module::Install prerequisite specifications.

Presence of an installed Alien::Foo should be considered evidence that libfoo is available. Alien::Foo must not install if libfoo cannot be found.

Library detection

Library searches will need to be done in platform specific ways. Perl Config values like "libpth" could be used as a starting point.

• Win32: should also include the LIB environment variable and possibly the PATH environment variable for library searches
• Unix: should include the LD_LIBRARY_PATH environment variable (or equivalents); could also use the output of "ldconfig -p"

Library configuration

• Makefile.PL: Alien::Base will provide an API for generating CC flags for both libraries and headers.
• Shared/dynamic library loading: Will need to set the shared library search path before bootstrapping XS. This could be done during import of "use Alien::Foo" or could be done via an explicit class method call.
• Other metadata: Alien::Foo could be extended with methods for library metadata.

Binary library package generation

Alien::Foo::* should include the full procedure needed to generate a binary library package (a ".pal" file) for a particular platform. This should include downloading sources from a URL, any preparation work or patching, and generation of the binary.

This process could be done completely from the upstream library source, or could be a "repackaging" of another binary download, e.g. creating wrappers or definition files around a .dll on Win32.

At worst, this might just be a series of system() calls. The point is to ensure that the full process is available for future packagers to replicate, adapt or enhance.

Alien::Base should provide helper methods for URL downloading, PAL file generation, etc.

After the PAL file is generated, it can be uploaded to a repository for end-users to download for installation.

Binary library package installation

If not available already in platform-standard library directories, the library headers and binaries should be installed into the corresponding "auto" directory for the Alien module. E.g., "site/auto/Alien/Foo" for Alien::Foo. This location should be well-defined for all platforms, since it's the same as is used for XS modules.

Exact layout within this module is still open -- should there be "lib" and "include" subdirectories or should libraries and headers be combined in the top directory. Installation location of binary utilities included with libraries is still an open question.

The binary package may be either generated from source or downloaded from a URL (the default option).

Strawberry Perl 5.8.8 Alpha 2 for Win32 is out. Largely synchronizes with Vanilla Perl Build 7, but with updates to CPAN.pm and other toolchain modules.

• Download strawbery-perl-5.8.8-alpha-2.exe (24.0 MB) (Changelog)

As of version 1.87_57, CPAN.pm has support for CPAN::Reporter. I wrote about this project in my last journal entry. At that time, one needed to install a subversion branch of CPAN.pm to use CPAN::Reporter. Now, it's easy to set up directly from the CPAN shell:

cpan> install ANDK/CPAN-1.87_57.tar.gz
cpan> install CPAN::Reporter
cpan> reload cpan

If you're not prompted to adjust your CPAN configuration settings -- including enabling CPAN::Reporter -- you need to do it manually:

cpan> o conf test_report 1
cpan> o conf commit

The first time CPAN::Reporter runs, it will create a default configuration file where you will need to put your email address, so just test CPAN::Reporter again to create the config file:

cpan> test CPAN::Reporter

Set your email address in ~/.cpanreporter/config.ini (found in "My Documents" for Win32) and you're ready to contribute to CPAN Testers.

There are certainly still bugs to work out, but the more people who give it a try, the sooner the bugs will be found. So please give it a go.

-- dagolden

I've just uploaded CPAN::Reporter to CPAN and it should soon be available on mirrors worldwide.

As part of my goal of improving the availability of test information for Vanilla Perl, I decided to try to get Test::Reporter working with CPAN rather than CPANPLUS. The result is CPAN::Reporter, though, along the way, I also wound up writing Tee for portability.

Standard CPAN.pm doesn't yet support it, but I'm consulting with the CPAN maintainer and have created a subversion branch with working support. It's now at the point where it could use some real-world testing and feedback before it can be considered for inclusion in the main line of CPAN. If you're not afraid of running bleeding edge CPAN code, please consider giving it a try.

Here is an excerpt from the CPAN::Reporter Pod -- please see the full documentation for more details, including how to install the CPAN.pm branch that supports it.

SYNOPSIS

1. Install a version of CPAN.pm that supports CPAN::Reporter
2. Install CPAN::Reporter
3. Edit .cpanreporter/config.ini
4. Test/install modules as normal with "cpan" or "CPAN::Shell"

DESCRIPTION

CPAN::Reporter is an add-on for the CPAN.pm module that uses Test::Reporter to send the results of module tests to the CPAN Testers project.

The goal of the CPAN Testers Projectis to test as many CPAN packages as possible on as many platforms as possible. This provides valuable feedback to module authors and potential users to identify bugs or platform compatibility issues and improves the overall quality and value of CPAN.

One way individuals can contribute is to send test results for each module that they test or install. Installing CPAN::Reporter gives the option of automatically generating and emailing test reports whenever tests are run via CPAN.pm.

Any other feedback or suggestions are greatly appreciated.