perl - 为什么不使用 CPAN 模块？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

6年前关闭。




Improve this question




ETA:当我问“为什么不使用 CPAN 模块？”时，我指的是拒绝使用 的人。任意 CPAN 模块(包括像 DBI 这样的高质量模块)。并非所有 CPAN 代码都是高质量的，远离琐碎或基于实验代码的模块是可以的(前几天我对一个开发人员很生气，因为他想要引入 Time::Format 只是因为他没有'不知道 strftime 在 POSIX 中)。

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

他们吓到你(回答，克服它)

他们吓到你的系统管理员(回答，解决他们
安装在您的主目录中并使用 lib pragma)

您使用的托管服务会阻止您
安装模块(回答，获得更好的服务，那里
是不像白痴的廉价服务)

目标机器不一定有需要
模块(回答，使用 PAR 或 PAR::Packer)

目标机器完全锁定(即您登录
到 rbash 并且必须向第三方提供代码
包含在盒子上)(4 和通过的组合
官僚机构)

您正在使用无法加载模块的嵌入式 Perl 版本(没有答案，您被卡住了，但这非常罕见)

那么，如果您不使用 CPAN，为什么以及为什么上面的答案不够充分？请注意，我不是在问您为什么不直接从 CPAN 在生产 boxen 上安装，而是在问您为什么避免使用 CPAN 中的模块(通过打包系统安装对我来说算作使用 CPAN)。

Answer 1

我有时建议人们不要使用某些 CPAN 模块有几个原因。并非所有 CPAN 都是高质量的代码，并且针对不同的发行版有不同的维护级别。每个人都应该考虑他们必须做多少工作才能使用特定的 CPAN 模块以及该模块为他们节省了什么(即总拥有成本)。使用任何特定的 CPAN 模块并不总是有益的。我并不是说人们不应该使用任何 CPAN，但他们应该考虑他们真正需要什么。

外部模块依赖项允许其他人破坏您的应用程序。 CPAN 工具链只关心模块的最新版本，当它看到您有较早版本时可能会升级您的安装。当底层的外部依赖项引入新的错误、不推荐使用的功能等等时，我已经看到许多应用程序崩溃了。这是我一直在为公司开发我的工具来托管他们自己的 CPAN 存储库以便他们可以控制它的原因之一。还有其他方法可以缓解这种情况，但没有多少人足够成熟，可以有一个好的流程。

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

一些 CPAN 模块实现了简单编码的功能。仅仅因为它在 CPAN 上而使用一个模块并且您不想自己编写这三行代码有点愚蠢。你可以随心所欲地谈论代码重用，但最终那是荒谬的。

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

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

对于使用其他服务、在本地目录中安装等的 glib 答案，您不会逃避这些原因。您不能将反论点应用于每种情况和设置。其他人告诉你的，比如 Top Seven (Bad) Reasons Not To Use Modules 的顶帖莱昂所链接的，并没有真正考虑任何人的情况，并且有许多深思熟虑的反反论点。

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