A framework for Alien modules (the Alien2 Manifesto)
The purpose of Alien modules is to provide external libraries or other dependencies for CPAN packages. This Alien2 Manifesto updates the original Alien module description based on practical lessons from existing Alien module implementations and some perceived limitations.
The original Alien manifesto provided the idea but not a framework for how modules in the Alien namespace were to work. The plan was to "let evolution work for us and see what individual Alien packages need and then eventually factor it out". We are now more than 10 years after this first proposal and there are now some lessons to be learned from current implementations of Alien modules. Let's start with a review of the responsibilities of an Alien module and some observations.
On installation, make sure the required package is there, otherwise install it.
This is the main purpose of Alien modules, to provided external library or program dependencies needed for CPAN modules installation and operation.
There are a couple of different approaches that are being used: (1) install the library from souce/binary no matter what, (2) detect and/or install the library but with a non-portable implementation such as relying on a unix-only build process. In many cases, the test reports for Alien modules are misleading, confusing, or useless (e.g., one module runs a test suite that skips the test for whether the package was actually installed so you get a PASS report even where it actually FAIL-ed to install).
On usage, make sure the required package is there, else croak.
Most implementations meet this requirement by simply not installing the Alien::XXX for XXX if library/dependency XXX could not be found or installed. This makes use of the default error handling from the perl compile phase.
An alternate approach would be to install an Alien/XXX.pm that actually checks if the package is there (perhaps from the build/configure/install information) and then croaks or whatever. This could provide additional information to the Alien::XXX consumer.
Bundle the source with the module, or download it.
A number of modules don't try to determine if there is a previously installed system version of the library/package/dependency. Often, the install process attempts to install into system-wide paths rather than an appropriate perl-specific local install path. There is also ambiguity in the case where a system-wide install is made after the Alien::XXX install and how to update or not the various modules.
Allow module authors to access information it gathers.
There is some necessary variability in the information provided by Alien modules to the modules use-ing them but it would be nice to see some standardization so that the common features and information could be accessed in the same way across platforms. pkg-config is a convenient framework and standard for autoconf/automake built tools or libraries. Maybe a portability implementation could be used for windows or other non-autoconf platforms.
Document itself well.
There is some wide variability in the quality of documentation provided by the various Alien modules. Probably the best way to characterize the problems in general is that they are written for those who are already familiar with the provided external package and any issues related to that ("well known to those who know it well"). The catch is that the purpose of the Alien module namespace is to provide libraries and packages precisely for those who don't already know everything they need to install and use the provided library/package/program. This is especially true for perl platforms without a standard package manager (i.e, windows).
What would be helpful would be for the Alien module to include a brief overview of the configure/build/installl approach, some information about the library/package, and links to the source, documentation, and/or binaries for that library/package. In addition, if the Alien module author knows, a priori, that they do not support a given platform, it should be clearly indicated in the documentation and README. Non-expert users should not have to read source code to determine the how, what, and why of an Alien module's implementation.
Preferably use Module::Build.
Having a perl-only build process is nicely clean and modular---in principle. In practice, the learning curve for Module::Build authors is rather steep. If an Alien module uses ExtUtils::MakeMaker, it can simply fail at the 'perl Makefile.PL' stage with a clear indication that a make program is needed and a set of options for the installer to obtain them.
Some nice work is underway on an Alien::Base module to provide the common parts of Alien module implementations based on Module::Build. It is still new and not yet mature in support for non-unix-ish platforms but work is on-going. (Contributors welcome!)
Be sane.
In the next installment of the Alien2 Manifesto, I'll propose some new standards for the implementation of Alien modules which I believe will greatly improve their portability, robustness, and usability.
I blog about Perl and PDL.
Since these days, read Linux for Unix, it'll probably have to be de-mangled to work on other unix-y systems too.
"Yay" it manually parses pkg-config files, that'll end well.
Maybe something like Brew for Mac would be good. Where it can fetch the package, and it has recipes for building the package for Mac. But what we would need is a cross platform recipes for building.