You might find PAR helpful.

This module lets you use special zip files, called Perl Archives, as libraries from which Perl modules can be loaded.

Or perhaps pp.

pp creates standalone executables from Perl programs, using the compressed packager provided by PAR, and dependency detection heuristics offered by Module::ScanDeps. Source files are compressed verbatim without compilation.

the Idea of packages is to make the main script look easy and simple and put all the reusable code and subroutines in packages, it seems that you have not understood that properly.

why can't you try exporter and include only those functions you require from those packages, this is one suggestion.

after saying this, another question arises in my mind, after how many subroutines we should look for moving it into a package, 5, 10 .. ?, i am not sure , so far i haven't defined more than two or three sub-routines in the main script, all the other statements are only function calling and flow control, but original functions would be got from modules.

targetsmart!

thanks for your an dall the other replies. i have indeed understood the usefullness of organising code in packages and subroutines and i do use it extensively (that's where my problem comes from). i just try to avoid copying all packages each time i want to pass on a small script to someone.

exporter would still need copying the packages. i see the problem mentioned by others that it's not an easy problem, at least not as easy as i thought. e.g. for object oriented code one would at compile time probably not know which routines are going to be needed.

anyway, i'll keep trying:)

Don't think of spoiling your(Perl's/OOP) principle for the sake of ease of use of others(may be beginners/end-users/etc). Just give them a tar ball of your modules, main script and a README, this seems to be one of the good solution, as CPAN does normally.


---

Vivek
-- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.

It may be that you are looking for Cava Packager? It goes a step or two further and can generate an installer for a complete install of a Perl script and the environment it needs (including the perl interpreter) as a stand alone application.

GrandFather, thanks for your answer. cava packager sounds like overkill for my problem.

my idea to extract single subroutines from packages seemed simple for packages that are merly collections of independend routines but gets difficult for e.g. OO code. therefor it's seems to be against the nature of code architecture where packages are independend units.

i'll think it over;)

my idea to extract single subroutines from packages seemed simple for packages that are merely collections of independent routines but gets difficult for e.g. OO code.

You're wrong there. In Perl, the module source file and the package name are often the same (after conversion) due to convention, but it doesn't have to be that way. You can easily stuff more packages in a single module file, or even in your main script.

That works particularly well for OO code, because in OO code you usually don't import anything from the package. And it's precisely the latter that can make things more tricky.

Some of the suggestions already made may be better, but if you really must inline a module, some more work will be required. Also note that Exporter will not work in an inlined module.

Basically, you can write a program with an inline OO module/class by putting its package into a BEGIN block. Copying an existing module into a BEGIN block should work with appropriate code adjustments. YMMV and you will need to experiment a bit.

#!/usr/bin/perl

use mymodules::foo; # Remove this line

   # main program here

exit;

# copy your modules into BEGIN blocks
# be prepared to tweak & debug

BEGIN{

    package mymodules::foo;

    sub new { ... }

    sub bar { ... }
    
    etc ...
}
[download]

You don't even need the BEGIN block:

#!/usr/bin/perl

use strict;
use warnings;

my $foo = Inline::Foo->new('Hello, world!');
$foo->display;


package Inline::Foo;

sub new {
  my $class = shift;
  return bless { text => shift }, $class;
}

sub display {
  my $text = $_[0]->{text};
  print "$text\n";
}
[download]

You don't even need the BEGIN block:

Maybe not in the examples shown, but what if Inline::Foo has a package global, or has some initialization code outside of the subs? Then the package must be either moved to the top of the program or enclosed in a BEGIN block. Also, a BEGIN block more closely simulates the behavior of a module that has been used, and I find that it helps visually identify an inlined class.

As for Inline::Module, I'll generally avoid modules that have virtually no documentation. However the example from Anonymous Monk clears it up a bit, so maybe it's worth a try.

You don't even need that, just use Inline::Module (for example)