Preface: the reason I'm pushing for this is that I have a packager like
PAR that does *not* build .exes but does use the simple expand-first,
ask questions later behavior I'm advocating here. So I have a narrower
set of expectations than other PAR users might. PAR is far superior in
many ways to my packager and I'd like to abandon mine and switch to PAR
completely.
On Mon, Jan 26, 2004 at 11:11:24PM +0800, Autrijus Tang wrote:
> ?b ä, 2004-01-23 19:55, Barrie Slaymaker ?g?D?G
> > What is the advantage of using the CODE refs in @INC?
>
> It makes it easier for people to dynamically add PAR files to @INC,
> which is why PAR exists in the first place.
How is this better than extracting a PAR file to a temp dir and adding
that temp dir to @INC, as you propose below? As long as it happens up
front, it should be transparent. A bit slower perhaps, but only for
large PAR archives.
Another thing I tripped over after writing the original message is that
[EMAIL PROTECTED] is not self-documenting in debug dumps. You can't see
what @INC *really* is by carp( join " ", @INC ), for instance.
> > Is there a disadvantage to just unzipping the packaged files in to a
> > temp dir and putting the appropriate entry in to @INC?
>
> I do not think those two approach needs to be mutually exclusive.
> Actually, I think what we need is, instead of the current scheme of
> creating a temp file for, say, IO::File in file1.par and DBI in
> file2.par:
>
> $PAR_TEMP/abcd0123.pm
> $PAR_TEMP/bcde5432.pm
>
> We ought to use:
>
> $PAR_TEMP/file1%2Epar/IO/File.pm
> $PAR_TEMP/file2%2Epar/DBI.pm
>
> and assign the two subdirectories to @INC, directly before our coderef
> hook. Of course, $INC{'IO/File.pm'} will be a physical file instead of
> a code reference.
Feedback:
- Yeah, baby! That is perfect. I don't think it breaks *any*
assumptions about behavior that existing Perl code makes.
- You would not need to set %INC in PAR (duh), require() would.
- I think this is the safest, conceptually simplest route and
therefore should be the default.
- This would add startup time the first run.
- Should not increase overall run time that much
- Does PAR keep $PAR_TEMP around now unless the clean option is
set?
- That means second and later starts would be very fast.
- The %2E is perhaps best left as a "." when not on VMS and the
filename begins with a non-".".
- This would make the paths easier to read and work with when
spelunking around to see what's what.
- For normal programs, you could elide the file1.par/ and file2.par/
intermediate dirs and just shove $PAR_TEMP on @INC. This
corresponds to exactly what would happen if you were to install
the two PAR archives' contents under $INSTALLSITELIB.
- Pros:
- This would make things simpler in the "normal" case.
- This would speed up @INC searches by both internals and by
scripts.
- Fewer @INC entries
- Lower directory hierarchy to search means faster path
name processing by the OS.
- This would use up fewer characters in the filepaths and
lower the (already minimal) risk of hitting OS path name
limitations.
- Cons:
- I'm pretending that PAR files only contain lib/...-like
file trees and that any collisions are ok because they are
collisions with or without this simplification due to
normal first-match @INC processing.
> Also -- I dislike needless pre-extraction. It penalize people using
> many PAR files, some of which may be remote. I can see that files other
> than .pm and .dll needs to be pre-extracted, though. Would be good
> enough for you?
I (did) need .pms, because they have POD I want Pod::Usage to find.
However, VCP's ok for now, I added a script and Makefile rule to
preextract all POD and subsets of POD and generate lib/VCP/Help.pm from
them with a giant hash and some accessors, and another script and
Makefile rule to build all the HTML. So VCP theoretically no longer
needs Pod::* foo, and thus works well with the current PAR.
I'm still willing to contribute to the cause, will discuss with you
privately.
> The risk is acknowledged. I'd love to hear comments form you and other
> folks about the new scheme outlined above.
See above :)
Digression: Seems like File::Spec could/should grow
File::Spec::*::escape() method that takes a path, runs it through
splitpath() and splitdir(), then escapes the various pieces of the path,
then joins 'em. Too many OSs with different filesystem syntaxes.
> Parl.exe needs only VC6 -- at least, that's what I'm using. :-)
So far, we're all Borland for our Win32 work here, so no joy there
either. I was tempted to write an unpacker/repacker for parl.exe so I
could modify parl.exe's bundled PAR.pm, but I didn't get far enough in
to it to see if it was as easy (like, I didn't get to checking whether
the PAR.pm in parl.exe is encoded as a C routine to print it out or if
it's packed in using the technique pp uses to append things).
I'll be forced to use VC6, etc, sooner or later, but I don't have it
now. Sigh.
- Barrie
