如何在没有自定义模块开销的情况下分发本地perl脚本？

Question

如何在不强制用户知道脚本运行所需的自定义（非CPAN）模块的情况下，如何分发本机（非“编译/ perl2exe/...”）Perl脚本？

问题是，用户将不可避免地将脚本复制到系统的其他位置，并将脚本从本机环境中取出，然后再无法找到需要运行的模块。

我有时只是将模块复制到实际的脚本中解决，但我更喜欢更清洁的解决方案。

更新：我更好地澄清。我分发了一些恰好在后端使用类似模块的脚本。用户知道如何运行Perl脚本，而不是依靠告诉他们“不要移动脚本”，我宁愿让他们移动文件。阻力最小的路径。

Answer 1

如果您为客户端准备的脚本需要“自定义”模块，则只需打包模块，就好像您尝试将它们上载到cpan一样。然后将包提供给客户端，他可以使用cpan实用程序来安装脚本和模块。

Answer 2

正确的方法是告诉他们“不要那样做！”我希望他们不会期望移动一个exe文件并让程序继续工作。这也不例外。

也就是说，有两种选择。一种是用包装器（例如pl2bat）替换脚本，该包装器知道真实脚本的完整路径。另一种方法是使用PAR，但这需要安装PAR和/或parl（来自PAR :: Packer）。

Answer 3

与脚本一起分发安装程序。安装程序将需要以root权限运行，并将自定义模块放入标准系统位置（/ usr/local/lib/perl5/site_perl或其他）。

我还没试过这个，但Module::Install在这方面看起来很有帮助。它描述为：

独立的，可扩展的Perl模块安装

Answer 4

这将是非常好的，如果你可以只使用一个NeXTSTEP style application包。既然你可能没有开发一个使用bundle的平台，你必须要做。

将所有支持文件放入已知位置，并将可执行文件指向这些文件以访问设置和库。最简单的方法是使用简单的安装程序。

例如，一个名为foo一个应用程序，把所有必需的文件在/opt/xlyd_apps/foo，图书馆/opt/xlyd_apps/foo/lib，配置/opt/xlyd_apps/foo/etc，等等。将可执行文件放入/opt/xlyd_apps/foo/bin。

重要的是要确保可执行文件知道在/opt/xlyd_apps/foo中查找它的所有好东西，因此如果客户/客户端将foo脚本移动到新位置，安装仍然有效。

因此，虽然您不能使整个事物自包含并可重定位，但您已使实际调用脚本可重定位。

Answer 5

由于“把你的模块都在一个地方，让你的应用程序意识到这一点”，将甚至可以跨多个计算机和网络的工作，也许你应该看看PAR::Repository分别PAR::Repository::Client的变体。您只需提供一个连接到存储库（通过文件系统或https）的单个二进制客户端可执行文件，并执行由用户请求的存储库提供的任意数量的程序（使用任意一组模块）。

如果用户很多，这对维护也有好处：只需更新存储库提供的软件，用户在下次启动程序时就会开始使用系统的更新代码。

Answer 6

我真的想出了我自己的解决方案，我很好奇它会有什么样的接待。

我写了一个脚本，它读取一个perl脚本并查找“use/require”语句。找到它们后，它会检查模块是否是标准库的一部分（查看/perl5/\d+.\d+[\d.]+/的模块路径），然后用两种不同的方式重写使用/需求行，具体取决于用法。

如果需要发现：

{ 
    ... inline the entire module here... 
} 

如果发现使用：

BEGIN { import Module ...imports seen... } 

：

BEGIN { 
    ... inline the entire module here... 
} 

如果使用有进口，立即按照上面

我明白这个不是使用XS模块，但我很好。大多数情况下，我只需要支持纯粹的perl模块。