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".

use ExtUtils::MakeMaker;

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

See the ExtUtils::MakeMaker documentation for more information.

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

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?

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

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);
[download]

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.

--
[ e d @ h a l l e y . c c ]

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.

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.