Wed Jan 11 16:51:38 2017: Request 119737 was acted upon.
Transaction: Correspondence added by kor...@mpi-cbg.de
Queue: Module-ScanDeps
Subject: Re: [rt.cpan.org #119737] Problems with detecting
DateTime::Format::Natural dependencies
Broken in: (no value)
Severity: (no value)
Owner: RSCHUPP
Requestors: webmas...@korten-privat.de
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=119737 >
Hi Roderich,
On 09.01.2017 12:20, Till Korten wrote:
> Hi Roderich,
>
> thank you very much for the quick fix :)
>
> answers to your comments below:
>
>
> On 07.01.2017 15:30, Roderich Schupp via RT wrote:
>> <URL: https://rt.cpan.org/Ticket/Display.html?id=119737 >
>>
>> On 2017-01-06 09:58:19, webmas...@korten-privat.de wrote:
>>> The problem is, that
>>> DateTime::Format::Natural.pm (~line 13) uses a whole host of packages
>>> with 'use base':
>>>
>>> use base qw(
>>> DateTime::Format::Natural::Calc
>>> DateTime::Format::Natural::Duration
>> PAR::Packer uses Module::ScanDeps to scan your program for modules that
>> it uses (recursively). And this is where Module::ScanDeps falls short
>> (quoted from its POD):
>>
>> Chunks that span multiple lines are not handled correctly. For
>> example, this one works:
>>
>> use base 'Foo::Bar';
>>
>> But this one does not:
>>
>> use base
>> 'Foo::Bar';
> that explains the issue, thanks for clarifying!
>>
>> Have you tried packing with "pp -x ..." or "pp -c ..."?
> no, I'll try that before updating PAR and let you know how it turns out.
I just tested the -x and -c flags:
-x does not work for my program because it is a service that does not
exit by itself and thus the compilation hangs, waiting for the program
to exit.
-c works perfectly :), thanks for pointing me towards that :)
>>
>> Anyway, I'm adding an explicit rule for DateTime::Format::Natural to
>> Module::ScanDeps
>> that should make it work "out of the box".
> thanks a lot!, i'll update PAR and test the fix (after testing 'pp -x'
> and 'pp-c').
I just updated PAR (1.014), PAR::Packer (1.036) and Module::ScanDeps
(1.23). However, that did not fix the issue for me. I guess, the fix did
not make it into the official cpan repository,yet. Is there a way for me
to test the fixed version already now or should I just wait for the next
release? (waiting is no problem for me since the -c flag fixed the issue
as well :) )
>>
>>> I also had to add '-M DateTime/Format/Natural/Lang/EN.pm'
>>>
>>> Interestingly, in this case the double colon notation did not work.
>> What exactly didn't work? I tried the following:
>> pp -o natural.exe -u -M DateTime::Format::Natural:: \
>> -E 'use DateTime::Format::Natural;
>> my $dt =
>> DateTime::Format::Natural->new->parse_datetime("tomorrow");
>> say "tomorrow is $dt";'
>>
>> This works,
> I am getting an error reported by eval that it cannot find
> DateTime/Format/Natural/Lang/EN.pm, if I add ' -M
> DateTime::Format::Natural::Lang::EN.pm'.
> The error appears in a module I am using (either MP3::Tag or
> Music::Tag::MP3). Apparently that module uses eval to execute
> DateTime/Format/Natural/Lang/EN.pm. However, since that is not my
> code, and there is an easy workaround (adding the aforementioned ' -M
> DateTime::Format::Natural::Lang::EN.pm' parameter to the pp command),
> I did not bother to find out what exactly is the issue. Interestingly,
> the workaround works even under windows when specifying the module
> with forward slashes (less surprisingly it also works on mac).
>
> Cheers and thanks again for your help!
>
> Till
Cheers
Till
