我被推入了“美妙”的Composer世界,因为PHP库开始不提供手动下载和安装源代码的简单方法。
我们有一个非常大的系统,有几十年的代码,所以一些不可避免的事情会发生,例如:
为一个主要的migration版本准备
在当前项目中使用新的库版本,而不中断依赖于旧库version
的30个以前的项目
我将选择Google/Cloud,因为它有几个依赖项,比如guzzlehttp。
如果我这样做了:
cd /libraries/composer/google/cloud/0.179.0
composer require google/cloud:0.179.0
cd /libraries/composer/different_vendor/package/version
composer require different_vendor/package:version
# pretend this different vendor requires a version of guzzlehttp which is incompatible with google/cloud
cd /libraries/composer/guzzlehttp/guzzle/7.4.2
composer require guzzlehttp/guzzle:7.4.2那么,我会有一个问题,写这样的代码吗?
<?php
require_once( '/libraries/composer/google/cloud/0.179.0/vendor/autoload.php' );
require_once( '/libraries/composer/different_vendor/package/version/vendor/autoload.php' );
require_once( '/libraries/composer/guzzlehttp/guzzle/7.4.2/vendor/autoload.php' );如果我需要谷歌/云在一个微型应用程序和口香糖在另一个,那么我需要导入谷歌/云应用程序,只是需要口香糖?
我只是想把我的注意力集中在作曲家的好处上,因为所有的博客都在不经意地说"jUsT uSe ComPOsEr“。我可以看出composer对于一次性设置it和遗忘it网络应用是如何有用的,这些应用程序大概运行在一个专用服务器上,但这与我们的生态系统相去甚远;一个为来自单个领域的部门请求的公共页面和各种微型应用提供服务的网站。
我完全明白为什么下面的代码会是一个问题,但我不认为会出现这样的需求:
<?php
require_once( '/libraries/composer/google/cloud/0.178.0/vendor/autoload.php' );
require_once( '/libraries/composer/google/cloud/0.179.0/vendor/autoload.php' );发布于 2022-05-12 17:22:19
简而言之,不能使用composer在同一项目中安装多个依赖项的版本。composer的全部目的是查看给定项目的所有依赖项,并安装一个在这种依赖关系组合下工作的版本。
我从您的措辞和示例中收集到的是,您管理的依赖关系库与实际项目是分开的。Composer旨在维护每个项目的独立依赖项,而不是手动管理所有项目使用的共享文件夹中的依赖项。
因此,如果您有30个项目,您应该在每个项目的根上有一个单独的composer.json文件,这将控制该项目的依赖关系,但是每个项目本身可能有不同的依赖项集。例如,这允许您一次将一个项目迁移到新的主要php版本和/或新服务器。
如果您已经创建了代码库,可以在自己的项目中重用,那么理想情况下,您可以将自己的共享库转换为私有的编写器包,然后将其作为依赖项安装在30个使用它的项目的composer.json中。此时,您可以拥有您自己的包的不同版本,并且google api之类的东西的依赖性在您自己的包的不同版本之间可能有所不同,然后30个项目中的每一个都可以要求您的包的版本最适合该项目。
https://stackoverflow.com/questions/72218295
复制相似问题