ETA:当我问"你为什么不使用CPAN模块？"时,我指的是拒绝使用任何 CPAN模块的人(包括像DBI这样的高质量模块).并非所有的CPAN代码都具有高质量,并且可以远离那些微不足道的模块或基于实验代码的模板(前几天我因为想要引入Time :: Format而对开发人员感到恼火不知道strftime在POSIX中.
最近在Perl初学者身上,有人想要知道如何做而不采用通常为该功能建议的Perl模块.他或她不想从CPAN安装模块.这让我想到了我看到人们避免使用CPAN的原因,我想出了这种行为的五个原因以及每个原因的解决方案:
他们吓唬你(回答,克服它)
他们吓唬你的系统管理员(回答,通过在你的主目录中安装并使用lib pragma解决它们)
您正在使用托管服务,阻止您安装模块(回答,获得更好的服务,有廉价的服务,不像白痴)
目标机器不一定有所需的模块(答案,使用PAR或PAR :: Packer)
目标机器被完全锁定(即你登录到rbash并且必须向第三方提供代码以包含在盒子中)(4和通过官僚机构的组合)
您正在使用无法加载模块的嵌入式Perl版本(没有答案,您被卡住,但这种情况非常罕见)
那么,如果你不使用CPAN,为什么,为什么上面的答案不够？注意,我不是在问你为什么不直接从CPAN安装生产盒子,我问你为什么要避免使用CPAN中的模块(通过包装系统安装就像使用CPAN一样).
我有时会建议人们不要使用某些CPAN模块.并非所有CPAN都是高质量的代码,并且针对不同的发行版存在不同级别的维护.每个人都应该考虑他们需要做多少工作来使用特定的CPAN模块以及该模块保存它们的内容(即总体拥有成本).使用任何特定的CPAN模块并不总是有益的.我不是说人们不应该使用任何CPAN,但他们应该考虑他们真正需要的东西.
外部模块依赖性允许其他人破坏您的应用程序.CPAN工具链只关心模块的最新版本,并且可以在看到您拥有早期版本时升级您的安装.我已经看到许多应用程序在底层外部依赖项引入新bug,弃用所需功能等时中断.这是我为公司开发工具以托管自己的CPAN存储库的原因之一,这样他们就可以控制它.还有其他方法可以缓解这种情况,但并不是很多人都足够复杂,无法为其提供良好的流程.
您在必须批准所有代码的环境中工作.这似乎是很多人的愚蠢要求,但风险管理人员也有工作要做.有时,遵守是由各种法律,护理标准等规定的.除非该模块真的会节省大量的时间和精力,否则可能不值得为此过程付出努力.真的,有多少人认真检查过从CPAN获得的代码？那里可能有任何东西.
一些CPAN模块实现了简单编码的功能.使用模块只是因为它在CPAN上并且您不想自己编写三行代码有点傻.您可以随心所欲地谈论代码重用,但最终还是可以减少代码重复.
某些模块的安装可能非常棘手,易碎且不可预测,有时这是由于需要构建和测试模块的长依赖列表,即使您不需要这些依赖项来实际使用模块.在自动化测试环境中处理这些情况需要大量的工作.
一些CPAN作者是实验编码员,而不是维护者.在他们的工作上创建依赖关系意味着你最终得到一个不受支持的模块,该模块没有得到修补,也没有其他人真正关心.对于某些重要项目而言,接受修补程序是一件非常重要的事情,如果不采用某些过程来使用本地修补版本并且不会被CPAN工具链覆盖,则无法修复无响应的作者.
您不会因为使用其他服务的glib答案,在本地目录中安装等原因而忽略这些原因.您不能将计数器参数应用于每种情况和设置.任何人都告诉你,比如排在前七名(不好)的原因,不使用 Leon链接到的模块,并不是真的在考虑任何人的情况,而且有很多有思想的反反驳论点.
不要从认为任何人应该或不应该使用CPAN的立场开始.评估当地情况,评估风险和回报,制定风险保障措施,明智地使用模块.这与任何其他严肃的软件开发或业务实践没有任何不同.
您可能会发现这篇文章(及其评论)很有趣.
我很高兴你问.
我想问一个问题,"为什么CPAN必须这么多？" 但当我(我想)已经知道答案时,我觉得不值得牺牲我的声誉.而且由于这个问题被标记为"主观",我会感谢你没有因为我个人对这个问题的态度而对我表示不满,即使你认为我是错误的或愚蠢的.
首先是一些背景:我在九十年代中期做了很多Perl编码并且很喜欢它,但最终得出结论,该语言缺少"真正的"面向对象编程所需的很多功能.几年后我成为了一名C++开发人员,现在我是一名非常技术性的项目经理.我仍然使用Perl进行脚本和数据处理以及其他一些零碎,并且最近开始使用Perl脚本来测试我们的编码器开发的Web服务.
无论如何,我来到堆栈溢出的项目管理,但留在Perl.我很高兴看到语言已经成熟,并且拥有各种奇妙的模块,如Moose和MVC以及模板等等,并希望使用它们......我会的.但这需要时间,而我现在只有几个小时的时间来处理它.为什么不容易？
但要回答这个问题......
首先是明显的答案:大多数Perl程序不需要CPAN模块.
有不止一种方法可以做到这一点.我不需要模块来做很多我会使用模块的东西,如果这很容易的话.例如,我一直使用split()和正则表达式解析XML文档.我知道这是错的(但恢复的第一步是承认你有问题).但是我可以在几秒钟内复制并粘贴代码,或者我可以离开并尝试使cpan工作一个月左右.
现在让我们更具争议性.CPAN很脆弱.今年早些时候,我尝试使用cpan来安装Moose,因为我已经阅读了很多关于它的东西,并且热衷于在Perl中进行适当的OO编程,并且它不会变硬/难看.所以我按照安装说明进行操作,并在最后一步中使用编译器警告的页面和页面进行转储之前按下"Y"数百次(似乎).我到底该怎么办？我的主要开发盒有一些半破的驼鹿模块,等待(我肯定)在我最不期望的时候咬我的屁股.大约两个月前,我还没有回来.我推测许多Perl/CPAN依赖于其他编程语言,这使得它更脆弱(与其库用同一种语言编码的语言相反).我进一步推测这样的经历会吓跑潜在的用户.
CPAN初学者的文档很差.无论如何,权威的CPAN文档在哪里？初学者的介绍和教程在哪里？我怎么知道那个？我一直在阅读CPAN文档几个月,并开始弄清楚事情的发展方向.(我看到CPAN上几乎所有单独的Perl模块都在内部进行了精美的记录,但是我花了很长时间才找到该文档.)
安装过程太难了.十年前,当包装数量减少,依赖关系减少时,四个步骤和数百个提示可能已经没问题,但现在它只是糟透了.为什么我不能在我的shell中键入类似'cpan-install Moose'的内容并完成它？这是特别奇怪的,因为高级用户经常声称可移植性是一种美德,引用了我仍然无法获得的包和PAR之类的东西.当很多人似乎想要这样做时,为什么在本地安装更难？
有一些令人烦恼的问题,比如我是否应该使用cpan或包管理系统安装CPAN模块,其中建议不一致.更一般地说:有不止一种方法可以做到这一点.当您开始使用高级Perl时,您必须决定如何安装模块以及使用哪些模块以及从哪里开始？记住你是一个初学者,文档有点碎片,学习曲线很陡峭.我的解决方案是尝试解决这个问题,而不是使用cpan,而我还读了一些.
最后,高级Perl的学习曲线非常陡峭.高级Perl用户显然不记得这个并且看不到它.IMO与最初构想的Perl之间存在着天壤之别 - 作为具有强大正则表达式的实用提取和报告语言 - 并将其用作具有OO和模板以及MVC和各种其他好东西的现代开发平台.我还没有找到从Perl临时使用到高级Perl使用的温和,增量路径.
你去吧 为咆哮道歉.
在本地安装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".要设置PERL5LIBCGI环境,请弄清楚如何在服务器配置中设置环境变量.在Apache中,我可以httpd.conf在.htaccess使用mod_env 中或使用mod_env.(谢谢,brian d foy)
您可能将Perl脚本引擎嵌入到主机应用程序中(例如,Web服务器或任何需要编写脚本的复杂应用程序),并且在该嵌入式上下文中有很多限制,例如无法加载文件.
如果事情"吓唬系统管理员",他们不希望你把它们放在机器上,不管你认为你会把它们放在哪里.商店有标准是有原因的.
CPAN模块没有责任分配.在我目前工作的商店里,我们与封装的会计软件提供商达成了这样的协议.如果我们的应用程序停机并且我们需要他们的专业知识,我们会在半夜打电话给他们.因为如果我们的计算非常糟糕,我们与他们的合同确保他们将支付部分账单,具体取决于他们在特定问题上的风险.
当你进入现实世界时,Perl脚本可以与40年历史悠久的硬壳COBOL一起运行,你可能会理解管理员在运行COBOL时比在"脚本"中更加轻松地依赖于热情爱好者,无论多么聪明.
这就是说,我现在的店是用Perl几分惬意用于非关键的脚本和报告,并会安装偶尔CPAN模块,但审批过程非常严格,沙盒测试是长的(且昂贵!),但使之成为可能.我只能想象他们可以批准一个或两个新模块,而不是50多个新模块,因为它会暴露出多少新情况.因此,如果有任何依赖性"不推荐用于生产代码"或"实验性",那么由"让我们只使用CPAN"创建的模块就非常多了.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
