在没有 Composer 的情况下使用 PHP 包答案

【问题标题】：Using PHP Packages without Composer在没有 Composer 的情况下使用 PHP 包
【发布时间】：2015-12-30 23:09:14
【问题描述】：

我正在为开发人员构建一个 SDK，用于为电子商务平台构建模块，这些模块将使用我们的 API 来启动新的创业公司。

显然使用 composer 是理想的，我现在正在这样做。但是，当我检查了目前大多数电子商务平台，或者至少是最流行的平台时，他们不使用 Composer。

所以我想知道获取所有我当前包所需的所有依赖项并将它们构建到独立 SDK 中的最佳方法是什么。

通过这种方式，我可以获得一个适用于作曲家和非作曲家平台的版本。

在设计模式方面是否有标准化的方法来做到这一点？我将如何以任何有组织的方式布置所有依赖包？

【问题讨论】：

与其说我只是回答指向 AWS 的模型，不如在您制定了自己的项目接受的策略后写一个自我回答。

标签： php composer-php

【解决方案1】：

没有依赖关系！

是的，认真的。如果您要开发一个使用 Guzzle 作为 HTTP 客户端的 API 客户端，您必须做出选择：使用 Guzzle 版本 3、4、5 还是 6？

Guzzle 3 已停止维护并被废弃。你不会想用它的。

Guzzle 4 也被视为报废，因为版本 5 来得非常快。没有人真正使用这个版本。

这归结为使用版本 5 或 6。但 Guzzle 在两个版本中使用相同的命名空间和可能相同的类名，但彼此不兼容。无论您选择哪个版本：您的客户会做出相反的选择 - 现在您有一个代码库，其中同时运行两个版本的 Guzzle - 这将不起作用。

如果您没有依赖项，而是在自己的代码库中交付所有内容，那么您的所有代码都在您的控制之下，并且减少了使用 Composer 作为工具来轻松安装所有依赖项的需要。您的包将包含所有内容，不太可能存在任何命名空间冲突。

您可以提供一个 ZIP 文件供下载。如果您另外提供 composer.json 以允许开发人员以这种方式包含您的包，那么每个人都会很高兴。

更新

现在，在发现每个人都认为我提议不要使用其他地方发明的东西是疯了之后，我要求你再次考虑一下这种情况：你发现你必须生成可能包含在代码库中的代码，该代码库是不使用 Composer 管理。这意味着您不知道那里放置了什么样的软件。

可能只是因为您在现有代码库中有一个 Guzzle 版本 - 无法检测到，因为没有 composer.json。现在你提供你自己的包和一个捆绑的 Guzzle 版本（不管它出现在那里的任何方式）。由于冲突，这可能会在某个时候使整个软件崩溃，因为自动加载当然会在某个时候合并，然后某些部分代码会请求加载一些 Guzzle 类，该类从两个不同版本中包含两次Guzzle。

在这种情况下会发生什么？事情会崩溃！

而且这是不可避免的。即使在能够使用 Composer 的幸运情况下，它也会发生冲突——软件不会崩溃，但不会安装整个软件包。好消息是：您会立即注意到这一点。

如果主要目标是提供任何人都可以在任何情况下使用的 API 客户端，而无需使用依赖项管理器：没有依赖项！

或者，完全确定您知道哪些软件已经在使用，并创建一个在任何情况下都不会发生冲突的包。但是，这仍然是一项工作，因为可能还会安装其他插件，其中可能包括冲突的软件。

我的中心点是：如果你没有像 Composer 这样的依赖管理器来管理依赖，你最好不要在自己的代码中包含依赖，这样可以很容易地将你自己的代码包含在某人中其他代码库。

上面的问题清楚地表明 Composer 在一般情况下不是一个选项。

现在，隧道尽头有一个亮点：当涉及到一般任务时，PHP-FIG 已经开始标准化应该利用互操作性的接口。对于 HTTP，标准是 PSR-7。

您可以提供一个依赖（并附带）PSR-7 接口的 API SDK，并要求 SDK 的用户提供实现该接口的 HTTP 客户端。

我看到的这种方法的问题是，如果你尝试使用 Guzzle，出于同样的原因，你仍然会遇到麻烦：现在唯一有效的选择是为 SDK 使用 Guzzle 6 - 如果 Guzzle 5 是已经在其他地方使用过？冲突！好处是：如果您已经在使用 Guzzle 5，则可以通过使用任何其他支持 PSR-7 的 HTTP 客户端来避免使用 Guzzle 6。

【讨论】：

如果-1 投票者能解释我的回答不好，那么所有人都会受益。
PHP 花了 15 年多的时间才达到可以使互操作性保持一致和可靠的地方。避免使用现有的共享代码是很糟糕的建议，因为版本控制没有用于处理它的工具（Composer）很复杂。 PHP代码中“不是在这里发明”的时代终于过去了。既然您强调使用 Guzzle 作为示例，您能否将 Guzzle 的所有功能替换为内置的 PHP 功能？是的。但是，除非您只使用其功能的一小部分，否则重新发明所有样板文件是徒劳的。
@MichaelBerkowski Internet 连接对于世界各地的许多人来说仍然不容易或不够好。 Composer 是一个依赖 Internet 的工具。
@sємsєм 建议下载的 ZIP 存档也依赖于 Internet。我认为可以安全地假设在服务器上运行 PHP 电子商务 Web 应用程序的任何人都具有可靠的连接性，因为它是集成和部署目标的服务器，而不是可能存在连接性的开发人员环境更有限。
@MichaelBerkowski 我完全同意你的看法。因此，我与作曲家一起开发这个的原因。遗憾的是，并非所有开发人员都使用 composer 构建他们的框架，因为他们迎合了无法访问其托管环境的消费者，这严重限制了您使用 composer 的能力。创建独立版本虽然需要更多工作，但也是让我们所有潜在客户使用我们产品的最佳解决方案。

【解决方案2】：

因为那些电子商务平台不使用composer，这并不强制你将composer排除在方程式之外。你不能将你的包作为插件/模块/任何东西分发给那个特定的电子商务平台，但你仍然可以在生产环境中使用 composer 的自动加载器。

您可以准备要在您的机器或构建服务器上部署的包，归档结果并分发归档。为简单起见，我的示例将假设您将在本地机器上准备您的包：

创建一个临时工作目录：
```
$ mkdir -p ~/.tmp && cd ~/.tmp
```
克隆你的包：
```
$ git clone <package>
```

安装依赖项¹

$ cd ~/.tmp/<package> && composer.phar install --no-dev --optimize-autoloader

或者如果您使用自动化工具执行此操作：

$ cd ~/.tmp/<package> && composer.phar install --no-ansi --no-dev --no-interaction --no-progress --no-scripts --optimize-autoloader

删除.git目录。
从 ~/.tmp/<package> 创建 zip/tar 存档
分发存档。

假设您的软件包已经是该电子商务平台的插件/模块，则可以照常从该 zip/tar 存档中安装它。

¹⁾关于--optimize-autoloader，请阅读Sven 的this answer，它解释了为什么在某些情况下无法帮助您的应用程序变得更快。 p>

【讨论】：

不要盲目用--optimize-autloader跑，如果不检查更快，多少。
@Sven 你能举一个具体的例子，classmap 比 PSR-0/4 慢吗？
所有细节都在这个答案中：stackoverflow.com/questions/22803419/… 它本质上是文件系统所需的最少查找工作量与总是浪费资源来创建类映射之间的权衡。