Alexandr Ciornii (CHORNY)
$2000
Many CPAN modules depend on non-CPAN libraries (or programs). Installation of such module requires that library be installed before installing CPAN module. For beginners it is more confusing as library may be installed, but its headers may not. I'd like to automate this step and install corresponding Linux package as part of module install.
Currently main module of this project has codename CPAN::non, it will be renamed later after discussion in module-authors mailing list.
For any user installing CPAN modules, as it will become much simpler. It is especially important when installing many modules or in case of inexpirienced user.
Module authors, because module installation will become easier and they would not need to periodically explain that users need to install non-CPAN library.
CPAN/OS porters, because dependencies will be listed more clearly, in future it may be also automated.
Package tools like Shipwright or carton can use CPAN::non to install OS packages.
New version of Linux::Distribution. XML::Parser will automatically install expat (of course if user agrees). Module for yum interaction. CPAN::non and Module::Install plugin will be released.
CPAN modules that want to get rid of this problem usually bundle libraries either directly or as Alien:: CPAN distributions. This creates several problems:
But it is easy to install such dependency with OS tools. CPAN module will have configuration file that will specify build and runtime dependencies. CPAN::non will be bundled with module, or installed using configure_requires in META.yml/json. In future OS vendors may include it into their versions of Perl.
CPAN::non will detect version of Linux, check if dependency and its headers are installed, find out which name has dependency and headers on this OS from configuration file, install it.
For yum there is no module CPAN, I plan to write module for it. Also there is no general module that would be dist-neutral, so I will write it too.
Module::Install plugin will be convenient as Module::Install allows automating bundling of run-time dependencies.
XML::Parser will be used as a first test for CPAN::non as I have comaint rights for it.
The project will take 2-3 months. I will start right after grant approval.
New versions of Linux::Distribution and XML::Parser.
CPAN::non, Module::Install plugin and module for yum released.
This project is a working solution, but after it will be adopted, more interesting things may be implemented, like support for FreeBSD, even Windows, support in tools for OS package generation, etc.
I maintain many CPAN modules and fixed bugs in many more. Participated in such projects as Strawberry Perl, Padre, ExtUtils::MakeMaker and others. Contributed to Module::Install. My CPAN account: http://search.cpan.org/~chorny/ and Ohloh: https://www.ohloh.net/accounts/chorny/positions.
For 9 years I was a lead programmer of credit card payment system InterCardPro. Currently work for kariera.md.
This seems fairly useful. I'd like to hear from people working on the Perl module toolchain to see if this fits their vision of how this sort of thing should work.
I can only reiterate what Dave said. Seems interesting and useful.
This seems useful, and see also Devel::CheckLib. A nice-to-have would be a way of installing by a non-root user, presumably by downloading and building C source. This would, conveniently, also let you support every other platform.
Why not use PackageKit instead of getting into the messy details of apt/yum/emerge/etc?
If you look at the "What software uses the PackageKit session API?" section of their website, you see that it's regularly used for installing missing dependencies in a distro-agnostic way.
(http://www.packagekit.org/pk-users.html)
@Rolsky: I have great respect for Chornii's many contributions, but as a toolchain person, I'm concerned that the proposed project -- while well intentioned -- is very narrow. It is Linux only. It seems unnecessarily tied to Module::Install and bundling instead of using configure_requires (supported in core Perl since Perl v5.10.1).
It also only benefits those distributions which are written/revised to use the CPAN::nom shim. I'd be more interested in a general solution that could be used as a common tool by CPAN clients, complemented by improvements in MYMETA to output library prerequisites. That would allow *any* external-library-using module to benefit (provided a user upgrades their CPAN client -- a classic tradefoff).
Overall, I'm neutral. More innovation along these lines would be great, but this isn't the way I'd go about it.