Bug #60697 for PAR-Packer: Switch to pp pack only architecture-independent (pure-perl) code

Tue Aug 24 14:07:40 2010 dorian [...] cpan.org - Ticket created

Subject:

Switch to pp pack only architecture-independent (pure-perl) code

Hello, I propose that PAR::Packer be given a switch to strip out architecture-dependent (i.e. XS) modules from the dependency inclusion list when packing a PAR. If I missed a method of doing this, then please direct me to it. My use case is that I want to use PAR to bundle up (a Catalyst app containing) data and modules that aren't on CPAN and deploy the result on a different architecture (Windows/AMD64). It seems that the system gets easily confused as to which module to use (namely DynaLoader version mismatches) and I would prefer to just leave the XS modules out of the bundle. Setting -m appears to pack all modules, even the pure-perl ones, into an architecture-dependent directory (pp 1.006). I would prefer to avoid trying to cross-compile a multi-arch dependency tree or anything like that; I'm perfectly content to install whatever XS modules the system requires to run. I'm mostly interested in using PAR to abridge the effort of managing data files and non-CPAN modules. Let me know what you think. Thanks, Dorian

Tue Aug 24 15:18:15 2010 RSCHUPP [...] cpan.org - Status changed from 'new' to 'open'

Tue Aug 24 15:26:01 2010 RSCHUPP [...] cpan.org - Correspondence added

On 2010-08-24 14:07:40, DORIAN wrote: Show quoted text

> I propose that PAR::Packer be given a switch to strip out > architecture-dependent (i.e. XS) modules from the dependency inclusion > list when packing a PAR. If I missed a method of doing this, then please > direct me to it.

This doesn't make sense to me, at least it doesn't warrant a new option to pp (if that's what you meant) - it already has far too many options for my taste. If you have special needs try to tailor what gets packed using -m and -X. Cheers, Roderich

Tue Aug 24 15:41:11 2010 dorian [...] cpan.org - Correspondence added

On Tue Aug 24 15:26:01 2010, RSCHUPP wrote: Show quoted text

> On 2010-08-24 14:07:40, DORIAN wrote:

> > I propose that PAR::Packer be given a switch to strip out > > architecture-dependent (i.e. XS) modules from the dependency inclusion > > list when packing a PAR. If I missed a method of doing this, then please > > direct me to it.

> > This doesn't make sense to me, at least it doesn't warrant > a new option to pp (if that's what you meant) - it already > has far too many options for my taste. > > If you have special needs try to tailor what gets packed > using -m and -X.

My thinking was that in order to do that I'd have to know up front which modules were XS in the entire dependency graph and which weren't. Unless I am making gratuitous assumptions, this entails either maintaining a list by hand or scanning. Since pp already performs this scan, that information is handy, and it seems a bit of a waste/error-prone to have to scan twice. I thought it would make sense to be able to, in one shot, say "omit all XS modules from this PAR". I'm not trying to make work for anybody here; I'm content to write the code myself. I find it puzzling that the desire to only pack pure-perl module dependencies into a PAR has never come up before. Is there something else I'm overlooking?

Tue Aug 24 15:52:08 2010 smueller [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #60697] Switch to pp pack only architecture-independent (pure-perl) code
Date:	Tue, 24 Aug 2010 21:51:58 +0200 (CEST)
To:	bug-PAR-Packer [...] rt.cpan.org
From:	"Steffen Mueller" <smueller [...] cpan.org>

Hi, Show quoted text

> Tue Aug 24 14:07:40 2010: Request 60697 was acted upon. > I propose that PAR::Packer be given a switch to strip out > architecture-dependent (i.e. XS) modules from the dependency inclusion > list when packing a PAR. If I missed a method of doing this, then please > direct me to it.

I suggest that you take a look at PAR::Dist::FromCPAN. It can generate individual .par files for CPAN distributions (and follow dependencies!). It can also merge the result. Since you want to exclude XS modules, you may want to skip the merging bit. Use the automatic detection of XS modules and then delete all produced .par files that aren't "anyarch". Thereafter, you can merge the remaining, pure-Perl .par's with, I believe, the merging function of PAR::Dist. Obviously, this is easily scripted. Best regards, Steffen

Tue Aug 24 16:10:23 2010 dorian [...] cpan.org - Correspondence added

On Tue Aug 24 15:52:08 2010, SMUELLER wrote: Show quoted text

> Hi, >

> > Tue Aug 24 14:07:40 2010: Request 60697 was acted upon. > > I propose that PAR::Packer be given a switch to strip out > > architecture-dependent (i.e. XS) modules from the dependency inclusion > > list when packing a PAR. If I missed a method of doing this, then please > > direct me to it.

> > I suggest that you take a look at PAR::Dist::FromCPAN. It can generate > individual .par files for CPAN distributions (and follow dependencies!). > It can also merge the result. > > Since you want to exclude XS modules, you may want to skip the merging > bit. Use the automatic detection of XS modules and then delete all > produced .par files that aren't "anyarch". Thereafter, you can merge the > remaining, pure-Perl .par's with, I believe, the merging function of > PAR::Dist. > > Obviously, this is easily scripted. > > Best regards, > Steffen >

So suppose I'm in my Catalyst app directory, and I want to make a PAR of it. I would type `make catalyst_par' and out pops a PAR (theoretically). The only problem is that PAR is full of XS so when I send it to the target (Windows) box and try to run it there, I find it very difficult to get it into a position in which it can cooperate. Namely, it picks the .pm files from the PAR and the .dll files from the system and complains that the versions don't match. Merely matching versions is a brittle solution. I tried invoking it in the way that promotes the system module search paths over the PAR but saw no change in behaviour. My thesis is that if those XS modules were not present in the PAR, things would in the very least be much less confusing. So, to produce an equivalent alternative solution of generating a PAR from a Catalyst app sans XS modules would entail a mountain of work, whereas it would be cheap and simple (and more broadly applicable) to do it within PAR::Packer.