Question

我有一个GoDaddy共享托管网站。

根文件夹为html

我将其用作测试服务器，因此html有几个子目录，如/site1，/site2，/site3。

我想安装和使用parse.com PHP SDK并且following this guide to set it up

我在服务器上安装了composer：

-bash-4.2$ curl -sS https://getcomposer.org/installer | php
#!/usr/bin/env php
All settings correct for using Composer
Downloading...

Composer successfully installed to: /home/content/08/555555/html/composer.phar
Use it: php composer.phar

我使用以下内容创建了composer.json：

{
  "require" : {
    "parse/php-sdk" : "~1.1.*"
  }
}

据我了解，我应该将此文件放在我的project folder中，这似乎意味着网站的根文件夹，例如我的示例中的site1，然后是cd到该目录， “使用install参数执行composer”。

但是，我希望能够在每个网站中加入解析SDK，例如/site1，/site2，/site3。

我是否需要在每个站点文件夹中添加composer.json，将解析文件夹放在html中并将路径更改为"../parse/php-sdk" : "~1.1.*"，或者是否有更好的方法来设置它？

Answer 1

Composer不是作为包管理器构建的，而是一个依赖管理器。不同之处在于，包管理器将包安装在一个中央位置供所有人使用，而依赖性管理器只在一个应用程序中本地安装。

Composer COULD也可以将软件包安装到一个中心位置：composer global require vendor/package，并在那里创建一个可供应用程序使用的自动加载器。当涉及使用多个集中安装的软件包的多个应用程序时，问题就开始了。

第一个问题：更新。前进到一个重要的新版本（即不仅是错误修正，应向后兼容，但新功能和包内部工作可能不兼容的更改）可能需要在应用程序中进行一些调整。现在，如果要更新中央包，则必须同时在所有应用程序中进行此类调整。这并非不可能，但通常它会禁止更新，因为没有人愿意在所有其他应用程序中完成额外的工作。

第二个问题：当使用仅应在本地为一个应用程序安装但需要集中安装的软件包组件的软件包时，Composer将无法识别此安装。您将此软件包安装两次 - 而且本地安装不需要与中央安装版本相同 - 这将导致各种可能的不兼容问题，这些问题确实难以调试，因为突然发生了订单自动加载会影响可能的结果。

虽然每个应用程序多次在同一版本中冗余安装相同的软件包并不是一个坏主意，因为它浪费了文件空间，但事实恰恰相反：文件空间很便宜，工作应用程序被认为值得超过硬盘驱动器上重复文件的成本。并且管理和更新单个应用程序的依赖关系的难易程度很难与中央安装相匹配。

PEAR使用了核心方法。维护者花费了大量的工作来保证向后兼容软件包的每个版本，即使今天的常规PEAR软件包向后兼容PHP 4.0也是如此。今天没有人喜欢使用PEAR，甚至在Composer复活之前都不喜欢使用PEAR。我认为这是一个强有力的指标，可以不在中央位置安装软件包。

使用composer来要求多个子目录共享的文件

1 个答案: