Michael G Schwern wrote:
> On Thu, Feb 08, 2001 at 12:07:18PM -0200, Branden wrote:
> > The issue is actually not auto-downloading modules and their
prerequisites,
> > but actually packaging several scripts and modules in one file, so as
Java's
> > jar do. I think supporting this would be neat.
>
> I thought about making a "par" utility. It would basically do this:
>
> # for each module needed...
> perl Makefile.PL PREFIX=foo LIB=foo/lib
> make test
> make install
>
> Then you just stick your program into foo/bin or something and tar it
> all up and ship it off. The "pun" utility (I couldn't resist) then
> untars the thing and runs "perl -Ifoo/lib foo/bin/whatever.plx".
That's what I was talking about.
Only have `par' copy the scripts to foo/bin itself and handle tar/gzip
(maybe using Perl modules internally, so that platform dependency issues are
isolated). Then it should save the file with a `.myarch.par' extension, to
signal it's a `Perl Archive' and it's intended to be used in the `MyArch'
architecture (replace `.myarch' with `.win32', `.linux-i386', ... and it
makes sense).
`pun' could then check the file extension and issue some warnings, like:
``You are trying to install a file for architecture `Linux-Intel386' on a
machine running `Windows32'.''
`par' should support deploying .src archives, to be built on the target
machine, supplying a Makefile or similar that would build all needed modules
at once. And `pun' should recognize them and actually start the make
processing (perhaps prompting the user for it).
`pun' should be able to install the modules on a directory specified when
creating the par (like foo/lib), on a user-specified directory (like
~/myperlscripts/foo-1.2/lib), or on the Perl's main modules directories,
where the modules would be shared. `pun' could yet check if modules shipped
with the par archive are already present on the system, and skip them (or
update the system's modules, if the shipped ones are newer and the user
grants permission to do that -- i.e. he trusts the par).
And, more importantly, `par' and `pun' must be shipped in Perl 6.0.0. That
was the big mistake in Java, they only introduced `jar' in 1.1, but then
Microsoft already used `cab's for that, and `jar' never got to work for
applets, since the two big browsers supported different things.
Shipping them would make everyone's life easier. Script developers, because
they could package their code and give simple instructions like ``download
the xyz-1.2.win32.par and run `pun xyz-1.2.win32.par', then run `perl
foo\bin\myscript.plx' to run the script''. And users, because they wouldn't
have to go into the issues of what are modules, how to get them and how to
build them. And specially Perl, because having easy ways of deploying and
installing scripts/programs would make much more developers make much more
scripts and tools available for a much more wider set of users.
>
> Any obvious flaws? Poke me enough and I'll get around to doing it.
>
If there anyone points flaws, I help doing this thing. I think we should
only wait for the definition of how building modules will be in Perl 6,
since I don't expect it to use `make', but rather a Perl-defined tool.
- Branden
