[Melbourne-pm] DateTime::TimeZone breaking under PAR?

Daniel Pittman daniel at rimspace.net
Tue Dec 23 00:17:28 GMT 2008


"Toby Wintermute" <tjc at wintrmute.net> writes:
> 2008/12/23 Johan Lindström <johanl at darserman.com>:
>> At 08:18 2008-12-22, Toby Wintermute wrote:

[administratively, it would be nice if you didn't CC subscription-only
 mailing lists in your posts; I am not a member of London.pm, so
 anything that goes to them is held for moderation...]

>>> When using it via a PAR archive, it refused to determine the local
>>> timezone.  (This was on a Debian Etch fresh install, albeit with
>>> upgraded PAR libraries, since the normal Etch ones are quite broken,
>>> and then confirmed on an Ubuntu Hardy setup as well.)

[...]

> It makes sense, I suppose, since the name of the module it attempts to
> load is generated procedurally.. but is a pain.
> Manually adding all the DateTime::TimeZone::* files (and while one is
> at it, the TZ::Locale::* files) did indeed fix the problem.
>
> However, this seems like a wider problem with using PAR files..

It is, and it isn't — the model of automatically scanning for
dependencies is good, but is never a substitute for knowing your tools.

Part of the reason for avoiding PAR in favour of something that packages
CPAN modules whole is that it saves you, the developer, needing to do as
much work to understand the dependency model *inside* the Perl module.

> How do you detect undetected runtime requirements?

Exhaustive tests, run on the packaged version of the code, not just the
blib version.

> Just install *every* requirement to a private INC, then PAR it in it's
> entirety?

That isn't a bad strategy; using something to build PAR files of CPAN
modules whole, rather than installing them on your system and using the
dependency detection, also works.

(You can, naturally, merge those PAR files into your final distribution,
 giving you the same "statically linked" final product.)

Regards,
        Daniel

PAR, bringing back memories of shipping C++ application software on a
dozen Unix derivatives, and the work required to manage testing and
distribution there.



More information about the london.pm mailing list