ibm1620 has asked for the wisdom of the Perl Monks concerning the following question:

Hi, monks,

I operate in a perlbrew environment in MacOS Monterey, using Perl 5.34.1. I'm trying to bundle a program to send to another Mac user who has only the MacOS-supplied v5.30.3 and has no Terminal experience (however, he can follow instructions!).

I've been trying to use App::FatPacker and have run into several problems.

1. My program uses Term::ReadLine, and I have installed Term::ReadLine::Gnu. fatpack file myprog produces a lot of messages like 

File /Users/chap/private/perl/fatlib/darwin-2level/auto/Term/ReadLine/
+Gnu/XS/get_history_event.al isn't a .pm file - can't pack this -- if 
+you hoped we were going to, things may not be what you expected later

[download]
I'm guessing that this isn't fatal, and that the fallback Term::ReadLine's will come to the rescue.

2. My program uses my own CLH_Utils.pm module which lives in the same directory as myprog. And this directory is listed in @INC. But the final myprog.packed.pl doesn't contain CLH_Utils.pm.

I tried using the "recipe" (fatpack trace --use=CLH_Util myprog / packlists-for / tree / file), but the result was no different.

The doc on fatpack is kinda slim, and I'm at a loss what to try next. I'd certainly appreciate any help!

Replies are listed 'Best First'.
Re: Need help using fatpack
by ikegami (Patriarch) on Apr 29, 2022 at 18:33 UTC

    Issue 1

    The file produced by fatpack installs a hook into the mechanism used by use/require/do. As such, fatpack can only package files which are loaded using use/require/do. It presumes that .pm are loaded this way, but it presumes that .al files aren't loaded that way. Thus the error.

    The .al files are probably Perl subs that are autoloaded (read from disk, compiled and executed when called). If so, it's possible that use/require/do is used to load them. And if that is so, it becomes an issue of convincing fatpack to treat .al files as .pm. It might already do that; the message might just be warning that things might not work.

    If they're not loaded using use/require/do, fatpack can't help you. The module won't be able to find these files when it looks for them.

    Issue 2

    fatpack relies on .packlist files created for installed modules. You could create one.

[reply]
[d/l]
[select]
      Re: Issue 2 --
      fatpack relies on .packlist files created for installed modules. You could create one.
      Well, not me :-) I created this:

      /Users/chap/private/perl/.packlist: 

      /Users/chap/private/perl/CLH_Utils.pm

      [download]
      and then ran fatpack pack, but the module was not placed in fatlib/, nor was it added to myprog.packed.pl.

      Can always send CLH_Utils.pm in addition to myprog.packed.pl and say "put these in the same directory" but a clean solution would be preferable.

[reply]
[d/l]

        That file name looks wrong. Not sure what it looks for, but it's always in auto in an directory in @INC. Maybe auto/CLH_Utils/.packlist?

[reply]
[d/l]
[select]
      My code doesn't directly reference those .al files; it doesn't even directly use Term::ReadLine::Gnu (which isn't allowed anyway). All my code does is use Term::ReadLine and somehow it chooses ::Gnu (rather than ::Perl or ::Stub).

      So near as I can gather, what you describe is all handled by the ::Gnu version of ReadLine.

      But it doesn't seem to matter. I copied myprog.packed.pl and CLH_Utils.pm to a virginal user on a MacOS Catalina with Perl 5.18 and it ran okay, apparently falling back to Term::ReadLine::Perl.

[reply]
[d/l]
[select]
Re: Need help using fatpack
by Fletch (Bishop) on Apr 30, 2022 at 03:57 UTC

    Maybe not ideal for this in particular instance (since you're using Term::Readline and would need a full terminal) but have you looked at Platypus? Haven't used it in a while but had in the past with some success. It'll wrap scripty things up as an application bundle. You could install whatever required libraries into a local::lib directory and then add that into the application contents (and add an appropriate incantation like use local::lib q{./my_libs}; to the main script).

    Edit: Actually thinking it over platypus would be using the os’ Perl so that’s another ding. You prossibly could also pack up a perlbrewed environment of 5.34 and have it run that instead, but that’s probably more work you’d need to do.

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

[reply]
[d/l]
      Yeah, it doesn't look like there's a super-simple solution. I think I may just have them install perlbrew > perl 5.34 and cpanm, and install the needed modules. (I think that's the only way for them to get Term::ReadLine::Gnu, which seems to handle line-editing keystrokes better than ::Perl.)
[reply]
Re: Need help using fatpack
by perlfan (Parson) on May 01, 2022 at 02:47 UTC
    I can't help but can comiserate with the lack of options for distributing applications. I would recommend you do your best to replicate your client's environment; even if that means using the system perl on MacOS. If all you're needing is to be able to install locally using cpanm (e.g.), then you don't actually need perlbrew. In addition to this, you can do your own "fatpacking" if it's "pure Pure" - just distribute your own tarball/zip with a thing/bin and thing/lib - if he can follow instructions, he can: update PATH and add PERL5LIB to his environment (or write him a starter shell script to do that). An additional lament is this: why aren't Perl modules that require compiled things on MacOS offered as packages in via brew like they are in every other package manager; brew definitely builds stuff, so it's not a matter of maintaining upstream binary packages. Whatever the answer, I'd love to see the Perl Foundation get more involved in enabling better Perl application distribution options for MacOS and Windows. This alone would get a ton more users to our "base".

    This Platypus thing does look interesting, I am going to have to play around with it.

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom