On Dec 21, 2006, at 4:20 PM, Glenn Linderman wrote:
I think the original renaming happened to avoid file name clashes
when extracting files to a single temp directory, rather than the
usual hierarchical structure used by perl/lib and perl/site/lib.
Later the hierarchical structure got some support for the .exe case.
Ahh! That makes sense. You're probably right, Glenn.
I really think that there should be an option for doing
hierarchical structure, which would also preserve the original
filenames, in cases that do not do it now. The only reason not to
make an option is if the hierarchical, preserved name case could
become the only supported technique... I would lobby for it to
become the default option, generally, but if there is some benefit
to the renamed files in a flat structure that I am missing, or if
it is felt necessary to support it for backwards compatibility,
then so be it... but the day the option exists, I will convert to
using it! Debugging with garbage names is a pain, besides the
other things that simply don't work, because the code is expecting
a particular file structure.
So if I read Chris' message correctly, he has problems because
files don't have the right names, and because they don't exist at
the right time either.
Correct. I had identified the former problem but actually the latter
one is an issue I had not realized until Steffen mentioned it.
So besides the option to use real names and real directory
structure, an additional option to "auto extract when opened" for
each .par file might be appropriate. The -clean option sort of
does that for .exe files, does it not? I say "sort of" because it
doesn't extract .dll files to the right place in the directory
structure, which has given me ongoing problems.
Yes, I agree (I think). The naming of files and full extract are
definitely two separate problems. I agree that the former should be
the default if there are no gotchas.
Regarding auto-extract, I see three possibilities:
1) Enhance Module::Pluggable to be smart about searching PARs
2) Add a "use PAR" flag to trigger full extraction
3) Add a flag to the par file itself to trigger full extraction
I would be happiest with #3, I think. That is, if I know I'm
packaging something that relies on a pluggable interface, I could set
a flag so it will completely extract on load. Full extract a lot
slower to boot than the incremental extract approach, so I don't
think it should be the default.
Would that per-par flag be feasible? Perhaps a flag in META.yml?
That way it would be automatically backward compatible.
Unfortunately, I don't have time to implement in the near future
(baby due any day), but I'm very interested in this.
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
