为什么不使用CPAN模块？

Question

ETA：当我问“你为什么不使用CPAN模块？”时，我指的是那些拒绝使用任何 CPAN模块的人（包括DBI等高质量模块）。并非所有CPAN代码都具有高质量，并且可以远离那些微不足道或基于实验代码的模块（前几天我因为想要引入Time::Format而对开发人员感到烦恼，因为他不知道strftime在POSIX）。

最近在Perl Beginners，有人想知道如何做而不采用通常为该功能建议的Perl模块。他或她不想从CPAN安装模块。这让我想到了我看到人们避免使用CPAN的原因，我想出了这种行为的五个原因以及每个原因的解决方案：

1. 他们吓唬你（回答，克服它）
2. 他们吓唬你的系统管理员（回答，解决他们的问题   安装在您的主目录中并使用lib pragma）
3. 您正在使用阻止您的托管服务   安装模块（回答，获得更好的服务，那里   是廉价的服务，不像笨蛋）
4. 目标机器不一定需要   模块（回答，使用PAR或PAR :: Packer）
5. 目标计算机完全锁定（即您登录   rbash并且必须为第三方提供代码   包含在框中）（4和通过的组合   官僚机构）
6. 您正在使用无法加载模块的嵌入式Perl版本（没有答案，您被卡住，但这种情况非常罕见）

那么，如果你不使用CPAN，为什么，以及为什么上面的答案不够？注意，我不是在问你为什么不直接从CPAN安装生产盒子，我问你为什么要避免使用CPAN中的模块（通过包装系统安装就像使用CPAN一样）。

Answer 1

我有时会建议人们不要使用某些CPAN模块。并非所有CPAN都是高质量的代码，并且针对不同的发行版存在不同级别的维护。每个人都应该考虑他们需要做多少工作来使用特定的CPAN模块以及该模块保存它们的内容（即总体拥有成本）。使用任何特定的CPAN模块并不总是有益的。我不是说人们不应该使用任何CPAN，但是他们应该考虑他们真正需要的东西。

1. 外部模块依赖项允许其他人破坏您的应用程序。 CPAN工具链只关心模块的最新版本，并且可以在看到您拥有早期版本时升级您的安装。我已经看到许多应用程序在底层外部依赖项引入新bug，弃用所需功能等时中断。这是我为公司开发工具以托管自己的CPAN存储库的原因之一，这样他们就可以控制它。还有其他方法可以缓解这种情况，但并不是很多人都足够复杂，无法为其提供良好的流程。

2. 您在必须批准所有代码的环境中工作。这似乎是很多人的愚蠢要求，但风险​​管理人员也有工作要做。有时，遵守是由各种法律，护理标准等规定的。除非该模块真的会节省大量的时间和精力，否则可能不值得为此过程付出努力。真的，有多少人认真检查过从CPAN获得的代码？那里可能有任何东西。

3. 某些CPAN模块实现了简单编码功能。使用模块只是因为它在CPAN上并且您不想自己编写三行代码有点傻。您可以随心所欲地谈论代码重用，但最终还是 reductio ad absurdum 。

4. 某些模块的安装可能非常棘手，易碎且不可预测，有时这是由于很长的依赖关系列表只是构建和测试模块，即使您不需要这些依赖项来实际使用模块。在自动化测试环境中处理这些情况需要做很多工作。

5. 有些CPAN作者是实验编码员，而不是维护者。在他们的工作上创建依赖关系意味着你最终得到一个不受支持的模块，该模块没有得到修补，也没有其他人真正关心。对于某些重要的项目来说，接受您的补丁是一件非常重要的事情，如果不采用某些过程来使用本地修补版本并且不会被CPAN工具链覆盖，则无法修复无响应的作者。

您不会因为使用其他服务，在本地目录中安装等的glib答案而忽略这些原因。您不能将计数器参数应用于每种情况和设置。任何告诉你的人，比如Leon所链接的Top Seven (Bad) Reasons Not To Use Modules中的最高职位，并没有真正考虑任何人的情况，并且有很多有思想的反反驳论点。

不要从认为任何人应该或不应该使用CPAN的立场开始。评估当地情况，评估风险和回报，制定风险保障措施，明智地使用模块。这与任何其他严肃的软件开发或业务实践没有任何不同。

Answer 2

您可能会发现this essay（及其评论）很有趣。

Answer 3

我很高兴你问。

我在想问一个问题，“为什么CPAN必须吸吮这么多？”但当我（我想）已经知道答案时，我觉得不值得牺牲我的声誉。而且由于这个问题被标记为“主观”，我会感谢你没有因为我个人对这个问题的态度而谦虚，即使你认为我错了或愚蠢。

首先是一些背景：我在九十年代中期做了很多Perl编码并且很喜欢它，但最终得出结论，该语言缺少“真正的”面向对象编程所需的很多功能。几年后我成为了一名C ++开发人员，现在我是一名非常技术性的项目经理。我仍然使用Perl进行脚本和数据处理以及其他一些零碎，并且最近开始使用Perl脚本来测试我们的编码器开发的Web服务。

无论如何，我来到堆栈溢出的项目管理，但留在Perl。我很高兴看到语言已经成熟，并且拥有各种奇妙的模块，如Moose和MVC以及模板等等，并希望使用它们......我会的。但这需要时间，而我现在只有几个小时的时间来处理它。为什么不容易？

但要回答这个问题......

1. 首先明显的答案是：大多数Perl程序不需要CPAN模块。

2. 有多种方法可以做到这一点。我不需要模块来做很多我会使用模块的东西，如果这很容易的话。例如，我一直使用split（）和正则表达式解析XML文档。我知道这是错的（但恢复的第一步是承认你有问题）。但是我可以在几秒钟内复制并粘贴代码，或者我可以离开并尝试让cpan工作一个月左右。

3. 现在让我们有点争议。 CPAN很脆弱。今年早些时候，我尝试使用cpan来安装Moose，因为我已经阅读了很多关于它的东西，并且热衷于在Perl中进行适当的OO编程，并且它不会变硬/难看。所以我按照安装说明进行操作，并在最后一步中使用编译器警告的页面和页面转储之前，按下“Y”数百次（似乎）。我到底该怎么办？我的主要开发盒有一些半破的驼鹿模块，等待（我肯定）在我最不期望的时候咬我的屁股。大约两个月前，我还没有回来。我推测许多Perl / CPAN依赖于其他编程语言，这使得它更脆弱（与使用相同语言编写库的语言相反）。我进一步推测这样的经历会吓跑潜在的用户。

4. CPAN初学者的文档很差。无论如何，权威的CPAN文档在哪里？初学者的介绍和教程在哪里？我怎么知道那个？我一直在阅读CPAN文档几个月，并开始弄清楚事情的发展方向。 （我看到CPAN上几乎所有单独的Perl模块都在内部进行了精美的记录，但是我花了很长时间才找到该文档。）

5. 安装过程太难了。十年前，当包装数量减少，依赖关系减少时，四个步骤和数百个提示可能已经没问题了，但现在它只是糟透了。为什么我不能在我的shell中键入类似'cpan-install Moose'的内容并完成它？这是特别奇怪的，因为高级用户经常声称可移植性是一种美德，引用了我仍然无法获得的包和PAR之类的东西。当很多人似乎想要这样做时，为什么本地安装更难？

6. 有一些令人烦恼的问题，比如我是否应该使用cpan或包管理系统安装CPAN模块，其中建议不一致。更一般地说：有不止一种方法可以做到这一点。当您开始使用高级Perl时，您必须决定如何安装模块以及使用哪些模块以及从哪里开始？记住你是初学者，文档有点碎片，学习曲线很陡峭。我的解决方案是尝试通过不再使用cpan来解决这个问题，而我还读了一些。

7. 最后，高级Perl的学习曲线非常陡峭。高级Perl用户显然不记得这个并且看不到它。 IMO与最初构想的Perl之间存在着天壤之别 - 作为具有强大正则表达式的实用提取和报告语言 - 并将其用作具有OO和模板以及MVC和各种其他好东西的现代开发平台。我还没有找到从Perl临时使用到高级Perl使用的温和，增量路径。

所以你去吧。为咆哮道歉。

Answer 4

在本地安装Perl模块有点挑战性。这是我的过程：

设置用户本地化的CPAN配置：

mkdir -p ~/.cpan/CPAN
touch ~/.cpan/CPAN/MyConfig.pm

如果以前为网站范围的管理员设置了CPAN（意味着，您已经在自己的框中并且已经启动并配置了CPAN），则可以通过以下方式更改为用户本地：“perl -MCPAN -e mkmyconfig”。然后，修改“~/.cpan/CPAN/MyConfig.pm”：

'makepl_arg' => q[LIB=/home/your_name/perllib],

否则，您可以正常启动CPAN：“perl -MCPAN -e shell”或只是“cpan”。系统将提示您进行配置。在“perl Makefile.PL'命令的参数？”下，输入：“PREFIX=~ LIB=~/lib/perl5”。

要在Perl脚本中引用本地安装的模块，您可以执行use lib编译指示，但我认为当您在应用程序中更新许多perl脚本和模块时，这是一个恼人的依赖项。这更像是一种解决方法。

相反，我可以将环境var PERL5LIB设置为本地安装模块的路径，例如“$HOME/lib/perl5”。要为CGI环境设置PERL5LIB，请弄清楚如何在服务器配置中设置环境变量。在Apache中，我可以使用mod_env在httpd.conf或.htaccess中执行此操作。 （谢谢，brian d foy）

Answer 5

您可能在主机应用程序中嵌入了Perl脚本引擎（例如Web服务器或任何需要编写脚本的复杂应用程序），并且在嵌入式上下文中有很多限制，例如无法加载文件。 / p>

Answer 6

如果事情“吓唬系统管理员”，他们不希望你将放在机器上，不管你认为你会把它们放在哪里。商店有标准是有原因的。

CPAN模块没有责任分配。在我目前工作的商店里，我们与我们的封装会计软件提供商达成了这样的协议。如果我们的应用程序停机并且我们需要他们的专业知识，我们会在半夜打电话给他们。因为如果我们的计算非常糟糕，我们与他们的合同将确保他们将支付部分账单，具体取决于他们在特定问题上的曝光率。

当你进入现实世界时，Perl脚本可以与40年历史悠久的硬件COBOL一起运行，你可能会理解管理员在运行COBOL时比使用“脚本”要多得多。然而，对于热心的爱好者来说，无论多么聪明。

也就是说，我目前的商店对Perl的非关键脚本和报告感到有些熟悉，并且会安装偶尔的CPAN模块，但批准过程非常严格，沙箱测试很长（而且价格昂贵！），但是有可能。我只能想象他们可以批准一个或两个新模块，而不是50多个新模块，因为它会暴露出多少新情况。因此，如果有任何依赖性“不推荐用于生产代码”或“实验性”，那么由“让我们只使用CPAN”创建的模块就非常多了。

Answer 7

这是我能想到的一个正当理由：你想弄清楚如何自己做。这很好，只要你意识到生产环境不适合你自己的个人实验。

有人可能会说“好好看看CPAN模块是如何做到的”，但是阅读其他人的实现并不能自己做。老实说，很多CPAN实现都是可怕的。这可能是对CPAN代码质量的贬低，但它也是一个成功的故事，关于CPAN模块封装和测试的大部分是你没有注意到的。

关于“CPAN shell难以设置”的所有答案，我同意。但是，这是一个O（1）问题。您只需解决一次，然后就可以轻松访问CPAN。

Answer 8

某些模块基于开源库，并且在您拥有的所有坚果环境中无法编译或表现良好。例如，考虑需要在NCR，HP，SUN，Linux和AIX上运行。

Answer 9

  

目标机器不一定具有所需的模块

这在某些环境中有效。我的一个朋友在跨越国家和大陆的巨型大型企业工作。通常，他使用perl来制作磁带驱动器，在世界各地做事。脚本必须部署在成千上万台机器上，安装模块是一件非常重要的事情 - 通常涉及一个委员会和每个物理位置的多个系统管理员。他不惜一切代价避免这些，我不能说我责怪他。

有解决方案吗？我真的不认为有。

（以上是我对permonks上一个非常相似的问题的回答。）

http://perlmonks.org/?node_id=750387

  

（回答，使用PAR或PAR :: Packer）

我确实曾向他推荐PAR，但这根本不实用。没有一台机器足够相似，PAR在一般情况下真的有用。他的选择是：不使用模块或维护1300 PAR二进制文件。即使你明确知道目标模式，PAR也很难很好地工作，所以他选择不使用模块。

Answer 10

目标主机有一个笨拙的操作系统，CPAN模块不能很好地支持（部分原因是缺少CPAN Testers）。

此类示例是AIX和HP-UX。他们有一个旧的perl，无论是C编译器还是旧的/破坏的和旧的/坏的库，因此太多的XS模块无法开箱即用。修补它们需要花费时间（特别是当CPAN作者几个月没有响应时），并且在实践中尝试解决XS模块是不可能的（好吧，如果你真的想这样做，你将经常修补纯perl模块这依赖于XS模块。）

Answer 11

这是积极方法的答案，即它说明了如何修复限制，使您无法使用CPAN模块：Yes, even you can use CPAN。