Re: Extract / Insert text files

John Nolan <[email protected]> writes:

> My only question is this:  Why can't the existing CPAN utilities
> for processing module tarballs be retrofitted for script tarballs? 
> The work required for making this happen has got to be exceedingly small. 
> Or am I missing something?  I've never understood what the obstacle
> actually is. 

Neither did I.

While we think that a script is just a plain (Perl) file, its
distribution involves just a little bit more. For example, a script
needs to be installed and, at least, the leading #! line needs to be
adjusted to the local Perl installation. The script can contain the
documentation in POD, but an acompanying README would be mandatory
since that is the first document you read to decide whether you are
going to use, even download, the kit.

Also, some kind of verification that the script actually runs and
produces the correct results should be included. By this time, we have
exactly what the modules tarballs have, or should have ;-).

Whether we use tarballs or self-extracting Perl scripts, its the
contents that matters. The packing format is less important, although
tarballs have proven to be widely accepted. Zip would be a useful
alternative. Text-based archives (shar, Perl) seem attractive since
you can easily extract the POD docs, but once you add uuencoding and
compression this advantage is lost.

So what are we waiting for? 

 1. A simple document that describes what need to be done to turn a
    useful script into a distribution kit (i.e. directory structure,
    sample files, Makefile.PL, etc.).
 2. A convention on the information that must be added to the README
    so external tools can extract data about requirements, platforms
    and so on.
 3. The tools mentioned in point 2.
 4. A simple document that describes how to install the kit if you do
    not have a decent 'make' program. 

> Why is a self-extracting Perl script better than a tarball? The only
> advantage I can see is that you can implement it without waiting for
> the CPAN maintainers to make any changes. But I think fixing CPAN is
> a better idea.

Can someone recap what fixes are required?

-- Johan