How to include CPAN packages in distribution package

[jeanluca]

Dear Monks
I've written some perl-packages that I distribute to others. Right now the installation is easy:

make clean
perl Makefile.PL
make
make install

(I've started the project with h2xs)
Anyway, thats all very nice, however, my packages require packages from CPAN, so I tell the users what else they should install.
I realize that this is not the perfect way of distributing software. Is there a way to automate this process (or include the CPAN packages in my distribution)?

Cheers
LuCa

Update: thnx to all. For the moment I'll go for the cpan . solution from eserte, it works and I can include that command in my installtion file!

[moritz]

You could use Module::Build to control the building and installation of your modules, and declare the right dependencies on the cpan packages. At least it will complain about missing deps.

Anybody who has perl installed has CPAN as well, and can install them easily.

If you upload your module to CPAN, you can automate the installation of all required modules by configure cpan to "follow dependencies".

[andreas1234567]

I'd look up some other modules on CPAN and use those as a starting point. E.g. the first lines of Makefile.PL from the most recent Test::Differences module looks like this:

use ExtUtils::MakeMaker;

WriteMakefile(
    NAME          => "Test::Differences",
    VERSION_FROM  => "Differences.pm",
    PREREQ_PM     => {
        "Text::Diff" => 0.34,
    },
);

Which basically says that Test::Differences requires Text::Diff in version 0.34 (or higher).

See the ExtUtils::MakeMaker documentation for more information.

[plobsing]

Have a look at Module::Install::Bundle. If users don't want to go to CPAN, this is the way to go.

[eserte]

If your users use a modern CPAN.pm, they need just to type

    cpan .
    # that is, cpan dot, in case your monitor is dirty, like mine

which would resolve all dependencies, make, test and install the application.

[girarde]

I suppose you could also include ppm, run it to check dependencies, and install the missing bits. But I've never tried that.

[johnnywang]

Wow, I'm just about to submit the same question when I see this post. Let me add a little detail to my version of the same question.

I'm trying to add a custom tool that needs a DBI/mysql combination, the perl installation doesn't have DBI/mysql. I'd like the user to be able to use my package (say via gunzip/tar) without installing any perl modules. What's the best way to package it?

[tsee]

If you are willing to ship binaries, the usual answer would be: use PAR;. You can also install .par files into the local system using PAR::Dist. To solve the bootstrapping problem (no PAR::Dist on the target system), you can just include that (pure-Perl) module into the installer script. Then it requires either Compress::Zlib and Archive::Zip to be present or an "unzip" tool. ActiveState's Win32 perl includes those modules. Unix usually has an unzip. Perl 5.10 will always include Compress::Zlib and Archive::Zip is pure-Perl and thus it's possible to inline it into the installer script. For an example, check out the local-path-installer script I hacked up for bugzilla .

As for the problem of the original poster: You could check out Adam Kennedy's "pip" tool.

Cheers,
Steffen

[halley]

If you intend to embed modules into your application, your application can use lib to find them in your own private library directory (a part of your application). After use lib, perl will see the updated value of @INC in its search for subsequent use statements.

BEGIN { $INSTALLDIR = my_fun_to_find_my_own_install_dir() }
use lib "$INSTALLDIR/privatelib";
use Acme::SuperModule qw(whatever);

The upside is that you have some control over the versions that folks will use, and thus you can more easily guarantee proper execution. The downside to this approach is that the writer of that embedded module (e.g., Acme::SuperModule) might fix a critical bug, and your customers won't get the benefits until you ship them a new version.

[johnnywang]

Thanks, I knew about "use lib" for my own lib paths, just never tried to have a CPAN module like DBI in my own path.

I just did a manual make of DBI from source, all the files are in the usual blib directory, I'm thinking that if I put everything of blib (except the docs) as part of my distribution (keeping the same structure like: lib/auto, lib/Bundle, lib/DBD, etc.) it should all work. I guess I'll just go ahead and do that, and report back.

Update Yes, it's as simple as that, I took the blib/lib directory, and moved it somewhere, and just do "use lib" to point there, all worked fine.

[redhotpenguin]

Krang has a nice system of managing packages, which includes being able to build the entire application from scratch. I use my Makefile.PL to document the dependencies, and also download a copy of that CPAN package to a src/ directory in my application. Because it's good to have it there if a few years down the road that package for whatever reason isn't on CPAN or BackPAN.