Skip Menu |

This queue is for tickets about the File-ShareDir-PAR CPAN distribution.

Report information
The Basics
Id: 49387
Status: open
Priority: 0/
Queue: File-ShareDir-PAR

People
Owner: Nobody in particular
Requestors: alex.peters [...] strategicdata.com.au
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.05
Fixed in: (no value)



Subject: Should File::ShareDir::PAR build-require PAR?
Hello Steffen, I am working on code that we intend to deploy in two styles: 1. as a standard installation (/usr/share/perl5, etc.) 2. as a stand-alone PAR Since this code uses shared files, File::ShareDir::PAR seems to be a perfect tool to accommodate for both cases. My understanding is that File::ShareDir::PAR intends to be a drop-in replacement for File::ShareDir--that is, if one is not operating under PAR, File::ShareDir::PAR delegates to File::ShareDir. To me, this suggests that File::ShareDir::PAR should be able to operate independently of PAR. However, File::ShareDir::PAR lists PAR as a build dependency. I understand that when File::ShareDir::PAR actually needs to call PAR, it requires a minimum PAR version. Therefore, I think I understand why PAR is listed as a build dependency: you want to ensure that File::ShareDir::PAR does not attempt to operate with an outdated version of PAR. However, since my code uses File::ShareDir::PAR even when PAR is not in use, PAR becomes a dependency for installations where it will never be required. To work around this, I am continuing to use File::ShareDir and dynamically requiring File::ShareDir::PAR when I detect that PAR is in use. Consequently, I am also doing the PAR version checking myself. In order to Debian-package File::ShareDir::PAR for internal deployment, I am also manually removing the PAR dependency. This feels like an incorrect way to solve the problem, but it is necessary for me to ensure that a Debian-packaged standard installation of my code does not depend on libpar-perl. To cut to the chase: given my use case, do you feel that it could be appropriate to change PAR from a required build dependency to a conditional dynamic runtime dependency? This would make File::ShareDir::PAR a true drop-in replacement for File::ShareDir, since it would work as expected without a PAR installation. I don't know whether the attached modification of _par_in_use would be sufficient, but your consideration and feedback would be much appreciated. :) Best wishes from Melbourne, Australia. --Alex Peters
Subject: _par_in_use.txt
# The minimum version of PAR required for correct functioning # of PAR-specific code. use constant MIN_PAR_VERSION = 0.989; # Whether the installed version of PAR is sufficient. our $par_is_adequate; sub _par_in_use { return 1 if $par_is_adequate; return() unless exists $INC{"PAR.pm"}; return() unless @PAR::LibCache; # If we get this far, PAR must be loaded. if ($PAR::VERSION < MIN_PAR_VERSION) { die sprintf( 'File::ShareDir::PAR has detected that PAR %s is in use, ' . 'but %s is required for File::ShareDir::PAR to work ' . 'properly', $PAR::VERSION, MIN_PAR_VERSION ); } $par_is_adequate = 1; return 1; }
Hi Alex, I'll include a full copy of your bug report here since I only just added the PAR mailing list as CC. On Wed Sep 02 22:50:23 2009, http://alexpeters.net/ wrote: Show quoted text
> Hello Steffen, > > I am working on code that we intend to deploy in two styles: > > 1. as a standard installation (/usr/share/perl5, etc.) > 2. as a stand-alone PAR > > Since this code uses shared files, File::ShareDir::PAR seems to be a > perfect tool to accommodate for both cases. > > My understanding is that File::ShareDir::PAR intends to be a drop-in > replacement for File::ShareDir--that is, if one is not operating under > PAR, File::ShareDir::PAR delegates to File::ShareDir. > > To me, this suggests that File::ShareDir::PAR should be able to operate > independently of PAR. However, File::ShareDir::PAR lists PAR as a build > dependency. > > I understand that when File::ShareDir::PAR actually needs to call PAR, > it requires a minimum PAR version. Therefore, I think I understand why > PAR is listed as a build dependency: you want to ensure that > File::ShareDir::PAR does not attempt to operate with an outdated version > of PAR. > > However, since my code uses File::ShareDir::PAR even when PAR is not in > use, PAR becomes a dependency for installations where it will never be > required. > > To work around this, I am continuing to use File::ShareDir and > dynamically requiring File::ShareDir::PAR when I detect that PAR is in > use. Consequently, I am also doing the PAR version checking myself. > > In order to Debian-package File::ShareDir::PAR for internal deployment, > I am also manually removing the PAR dependency. This feels like an > incorrect way to solve the problem, but it is necessary for me to ensure > that a Debian-packaged standard installation of my code does not depend > on libpar-perl. > > To cut to the chase: given my use case, do you feel that it could be > appropriate to change PAR from a required build dependency to a > conditional dynamic runtime dependency? This would make > File::ShareDir::PAR a true drop-in replacement for File::ShareDir, since > it would work as expected without a PAR installation. > > I don't know whether the attached modification of _par_in_use would be > sufficient, but your consideration and feedback would be much > appreciated. :) > > Best wishes from Melbourne, Australia. > > --Alex Peters
I can see where you're coming from and I'd be willing to apply the patch, but it'll take at least a modification of the test suite to skip the PAR-related tests if PAR couldn't be loaded. If you could also provide that, I'll apply both patches and cut a release. Thanks for feeding your improvements back upstream! Best regards, Steffen
From: Alex Peters
On Thu Sep 03 03:43:05 2009, SMUELLER wrote: Show quoted text
> I can see where you're coming from and I'd be willing to apply the > patch, but it'll take at least a modification of the test suite to skip > the PAR-related tests if PAR couldn't be loaded. If you could also > provide that, I'll apply both patches and cut a release.
Thanks, Steffen. I will get back to you soon with code, test and document patches. Cheers, Alex
CC: par [...] perl.org, jesse+par [...] bestpractical.com
Subject: Re: [rt.cpan.org #49387] Should File::ShareDir::PAR build-require PAR?
Date: Fri, 11 Sep 2009 09:38:46 +0200
To: bug-File-ShareDir-PAR [...] rt.cpan.org
From: Steffen Mueller <nj88udd02 [...] sneakemail.com>
Hi Alex, http://alexpeters.net/ via RT wrote: Show quoted text
> On Thu Sep 03 03:43:05 2009, SMUELLER wrote:
>> I can see where you're coming from and I'd be willing to apply the >> patch, but it'll take at least a modification of the test suite to skip >> the PAR-related tests if PAR couldn't be loaded. If you could also >> provide that, I'll apply both patches and cut a release.
> > Thanks, Steffen. I will get back to you soon with code, test and > document patches.
not to rush you, but I'd hate if this got lost. Did you make any progress? Best regards, Steffen
Hi Steffen, On Fri Sep 11 03:40:26 2009, nj88udd02@sneakemail.com wrote: Show quoted text
> not to rush you, but I'd hate if this got lost. Did you make any > progress?
Unfortunately I got pushed onto another work project not using PAR. I will get back to you in the near future though with the patches as promised. Cheers, Alex
Hi Steffen, On Wed Sep 30 23:54:04 2009, http://alexpeters.net/ wrote: Show quoted text
> Unfortunately I got pushed onto another work project not using PAR. > I will get back to you in the near future though with the patches as > promised.
I'm really sorry, but I'm probably not going to be able to fulfil my promise on this ticket. I don't know when I may end up working on another project involving PAR, so it is no longer realistic for me to block progress on this ticket by claiming to be working on it. If I find myself on another PAR-related project and no one else resolves this issue in the meantime, I will contact you again to claim it. Best wishes, Alex