develooper Front page | perl.par | Postings from September 2008

Re: PAR and modules, accessing the lib directory

Thread Previous | Thread Next
Steffen Mueller
September 1, 2008 03:29
Re: PAR and modules, accessing the lib directory
Message ID:
Hi Alvar,

I just spent my spare time budget for the day on the Storable/pp --clean
thread, so I'll have to be very brief.

Alvar Freude wrote:
> since some time, PAR unpacks only the used modules und give them more or 
> less random names.

That depends on how you use it. If you use it with .par files, or with
standalone exes *AND* --clean, then you're right.

> This makes a lot of trouble with modules, which access the lib directory 
> or itself, e.g. for looking into the POD, searching some files or loading 
> all available modules/plugins.
> Modules with such troubles include DBIx::Class, XML::SAX, Getopt::Euclid 
> and much more.
> And it is also not as easy to include and load some extra files (-a to 
> pp) in a .par, because extra code is needed to use this.


> I don't know the real reason, why PAR unpacks the used modules not with 
> their original path and name. But I strongly suggest to add an option, 
> that allows to unpack all modules with correct path and name and which 
> allows to unpack all files or a list of files/folders.
> Both would make it much easyer to use PAR in real life applications!
> Perhaps the is such an option, but I found nothing ...

There isn't. This discussion comes up a lot. There were a couple of
reasons for the behaviour, but nowadays, I just wish it wasn't so.

The main problem with changing the behaviour is that nobody has the time
to do it. It potentially breaks all kinds of things, so it's not *only*
a matter of patching the source in many places, but also a question of
who's going to deal with the fallout.

One problem is that in those scenarios, PAR does extraction on demand
only -- sort of like lazy evaluation. So if we change to the normal file
naming scheme for extraction, little is gained for those modules which
scan @INC manually, since what they're searching for might not be there
yet (or at all).

Then again, switching to burst-extracting all loaded .par files may be a
bad idea in the advertised "use PAR '/foo/bar/*.par';" chainsaw
approach. It implicitly assumes that opening a bunch of .par files at
startup isn't prohibitively expensive.

All this is conceptually fixable, I think, but it takes a lot of work
that nobody is currently able to do.

Actually, now that I think about this some more: Scott Stanton put in
some work to load Perl modules from memory instead of extracting them at
all. This isn't in the main line but in a branch because it creates
other problems. However, this also speeds up PAR operation in --clean
mode a lot, but totally breaks the manual @INC scans. I hate those
modules which do that. Maybe there should be an abstracted way of doing
that which respects PAR. Those modules which need to scan @INC could
then use that... nevermind, I'm day-dreaming.

Brief, yeah, I know, sorry.

Best regards,

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About