PHP：使用 Pecl/Pear，还是构建我自己的系统？
在构建我的一些 PHP 应用程序时，很多功能都可以使用 PEAR/PECL 模块进行编码，然而，事实上，有些使用它的人可能无权安装东西，这给我带来了困惑。
我是否应该放弃一些用户而使用 PEAR/PECL 来实现功能，这些功能将使我能够比编写自己的功能更快地编码系统，但这意味着它将排除某些人使用它。
When building some of my PHP apps, a lot of the functionality could be coded using PEAR/PECL modules, however, the fact that some people using it may not have the access to install things, It poses a puzzler for me.
Should I forsake some users to use PEAR/PECL for functionality, where these will allow me to have a system coded up quicker than if I wrote my own functionality, but eans that it will exclude certain people from using it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
重申已经说过的大部分内容： http://www.codinghorror.com/blog/档案/001145.html
Reiterating much of what's already been said: http://www.codinghorror.com/blog/archives/001145.html
你需要小心，因为 pear 中的很多模块的质量确实很低。
有些很棒，不要误会我的意思，但不要因为梨中的任何东西而认为梨中的任何东西都具有任何特定的品质。 这意味着您在决定使用 pear 模块之前至少需要浏览一下它的源代码，对于足够简单的任务来说，这可能比不使用 pear 需要更多的时间。
然而，pecl 不同。 扩展往往会经过更好的审查和测试，否则它们会使 php 崩溃。
You need to watch out because a lot of modules in pear are really of pretty low quality.
Some are great, don't get me wrong, but don't assume that anything in pear, by virtue of being in pear, is at any given quality. Which means you need to at least skim the source of a pear module before deciding to use it, which for simple enough tasks may take more time than going without pear.
pecl is different, however. Extensions tend to be better vetted and tested, else they'd crash php.
使用 PEAR 没有问题，如果用户没有 Web 服务器的 root 访问权限，他们可以简单地从 pear.php.net 下载 PHP 文件并将其添加到他们的包含路径中。 PECL 的解决起来有点棘手，因为没有 root 访问权限通常无法安装新模块。
Using PEAR is no problem, if users do not have root access to their webserver, they can simply download the PHP files from pear.php.net and add it to their include path. PECL's a little more tricky to work around, since there's often no way to install new modules without root access.
我大多数时候所做的就是永远不会使用在服务器上全局安装的 PEAR。 版本可以更改并影响您的应用程序。相反，我有一个配置文件（在我的例子中为 XML），其中列出了所需的所有包及其版本。 安装程序连接到我的个人 FTP 存储库，并在 $PROJECTBASE/lib/pear/ 中本地下载并安装所有 PEAR 软件包。并且 PEAR 是在本地运行而不是全局运行。 您可能需要考虑的事情。
What I do most times is I'll never use PEAR installed globally on a server. Versions can change and affect your application.. Instead I have a config file (in my case XML) that lists all the packages required and their versions. The installer connects to my personal FTP repository and downloads and installs all the PEAR packages locally in $PROJECTBASE/lib/pear/ .. And PEAR is run locally instead of globally. Something you may want to consider.
使用 PEAR，但允许在项目中包含 PEAR 包。 所有 PEAR 包都可以从 http://pear.php.net/ 单独下载，并可以放在任何地方。 根据便利性和许可问题，您可以将所有必需的 PEAR 文件与您的项目打包在一起，或者告诉用户如何下载和“安装”它们。
Use PEAR but allow for including the PEAR packages inside your project. All PEAR packages can be separately downloaded from http://pear.php.net/ and can be put anywhere. Depending on convenience and licensing issues you could then package all the required PEAR files with your project or tell users how to download and "install" them.
最初使用 PEAR/PECL 对其进行编码，如果有人要求非 PEAR/PECL 版本，请开始为此类版本编写您自己的替代方案。
这样，初始开发会更快，并且您可能会发现，一旦您开始发布应用程序，就没有人关心需要第 3 方库了。
Code it initially using PEAR/PECL and if you get people asking for a non PEAR/PECL version, start coding your own alternatives then for such a version.
The initial development will go much faster with this, and you may find that no-one cares about requiring 3rd party libraries once you have started releasing apps.
我的建议是从假设 PEAR/PECL 模块开始，然后完成其余的代码。 然后，一旦您的大部分代码按照您想要的方式工作，您就可以评估返回并用您自己的代码逐段替换外部代码。 另外，到那时您将更好地了解使用这些对您的用户群的影响。
My suggestion is to start with assuming PEAR/PECL modules, and get the rest of the code done. Then, once you've got most of your code working the way you want, you can evaluate going back and piece by piece replacing the outside code with your own. Plus, by then you'll have a better idea of the impact using those has on your userbase.
通过使用 pear 库进行开发来节省开发时间，并提供捆绑在您分发的内容中的库（尽管您必须确保它遵守许可要求）
我不会依赖于安装的某些 PECL 扩展，除非您正在做某事特别是与一个（例如 XDebug Web 前端或其他东西）相关，大多数安装将携带一组相当普通的扩展。
Save on development time by developing with the pear libraries, and provide the libraries bundled in what you distribute (though you'll have to make sure it obeys licensing requirements)
I would not depend on certain PECL extensions being installed unless you're doing something particularly related to one (say an XDebug web-frontend or something), the majority of installs will be carrying a fairly vanilla set of extensions.
这部分取决于您有多少时间以及项目的目的。 如果您只是想做出一些有用的东西，请选择 PEAR/PECL。 如果您想学习成为一名更好的程序员，并且您有时间，那么我建议您努力编写自己的版本。 一旦您了解了要替换的内容的内部结构，您可能想要切换到 PEAR/PECL 版本，这样您就不会浪费时间重新实现已经实现的内容...
...但另一方面，现有的工具并不总是完全满足您的需要，有时还会产生对您没有任何好处的开销。 这就是 Unix 命令行工具如此小且用途如此狭窄的原因。 没有人真正需要一个除了“ls”当前可以做的事情之外还可以做任何事情的“ls”版本。 任何 PEAR 库的版本，由于是由您编写的，都将完全执行您需要执行的操作。 这需要一些仔细的思考……
但在紧握的手上，不要花太多时间思考。 花五分钟，做出决定，然后开始编码。 即使你做出了错误的决定，你至少也会得到更多的编码练习。 :-)
It partly depends on how much time you have, and the purpose of the project. If you're just trying to make something that works, go with PEAR/PECL. If you're trying to learn to be a better programmer, and you have the time, then I'd recommend taking the effort to write your own versions. Once you understand the innards of whatever you're trying to replace, you may want to switch to the PEAR/PECL version so that you're not wasting time reimplementing what has already been implemented...
...but on the other hand, preexisting tools don't always do exactly what you need, and sometimes have overhead that doesn't do you any good. This is why Unix command-line tools are so small and narrow of purpose; nobody really needs a version of 'ls' that can do anything besides what 'ls' can currently do. Your version of whatever PEAR library will, by virtue of being written by you, do exactly what you need doing. It requires some careful thought...
...but on the gripping hand, don't spend too much time thinking about it. Spend five minutes, make a decision, and start coding. Even if you make the wrong decision, you'll at least have gotten more practice coding. :-)