Front page | perl.perl6.language |
Postings from February 2001
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. - BrandenThread Previous | Thread Next