7

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

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

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

更新：我最好澄清一下。我分发了一堆恰好在后端使用类似模块的脚本。用户了解如何运行 Perl 脚本，但与其依赖于告诉他们“不，不要移动脚本”，我更愿意简单地允许他们移动文件。阻力最小的路径。

4

6 回答 6

6

正确的方法是告诉他们“不要那样做！” 我希望他们不会期望移动 exe 文件并让程序继续工作。这没有什么不同。

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

于 2009-11-10T19:08:21.887 回答
4

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

于 2009-11-10T19:05:09.093 回答
2

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

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

于 2009-11-11T09:13:31.467 回答
2

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

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

独立的、可扩展的 Perl 模块安装程序

于 2009-11-10T19:10:33.013 回答
0

如果您可以只使用NeXTSTEP 风格的应用程序包，那就太好了。由于您可能不是为使用捆绑软件的平台进行开发，因此您必须凑合着做。

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

例如，使用名为 的应用程序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脚本移动到新位置，安装仍然有效。

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

于 2009-11-11T07:50:47.013 回答
-3

我实际上已经提出了自己的解决方案，我很好奇它会有什么样的接收。

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

如果找到需要：

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

如果发现使用：

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

如果use有imports，请立即在上面执行：

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

我知道这不适用于使用 XS 的模块，但我对此很好。大多数情况下，我只需要支持纯 perl 模块。

于 2009-11-11T15:53:20.127 回答