update
This commit is contained in:
bcw
parent
53949d3d76
commit
454ddc3b24
|
|
@ -11,7 +11,7 @@
|
|||
- [包版本](#Package-Versions)
|
||||
- [下一个重要版本（波浪号运算符）](#Next-Significant-Release)
|
||||
- [稳定性](#Stability)
|
||||
- [安装依赖关系](#Installing-Dependencies)
|
||||
- [安装依赖包](#Installing-Dependencies)
|
||||
- [`composer.lock` - 锁文件](#composer.lock-The-Lock-File)
|
||||
- [Packagist](#Packagist)
|
||||
- [自动加载](#Autoloading)
|
||||
|
|
@ -132,7 +132,7 @@ php composer.phar
|
|||
默认情况下只有稳定的发行版才会被考虑在内。如果你也想获得 RC、beta、alpha 或 dev 版本，你可以使用 [稳定标志](04-schema.md#Package-links)。你可以对所有的包做 [最小稳定性](04-schema.md#minimum-stability) 设置，而不是每个依赖逐一设置。
|
||||
|
||||
<a name="Installing-Dependencies"></a>
|
||||
## 安装依赖关系
|
||||
## 安装依赖包
|
||||
|
||||
获取定义的依赖到你的本地项目，只需要调用 `composer.phar` 运行 `install` 命令。
|
||||
|
||||
|
|
|
|||
|
|
@ -156,7 +156,7 @@ hg) 的信息推断出包的版本，因此你不必手动指明版本号，并
|
|||
|
||||
更多关于包的来源是如何工作的，以及还有什么其他的类型可供选择，请查看[资源库](05-repositories.md)。
|
||||
|
||||
这就是全部了。你现在可以使用 Composer 的 `install` 命令来安装你的依赖关系了！
|
||||
这就是全部了。你现在可以使用 Composer 的 `install` 命令来安装你的依赖包了！
|
||||
|
||||
**小结：** 任何含有 `composer.json` 的 `GIT`、`SVN`、`HG` 存储库，都可以通过 `require` 字段指定“包来源”和“声明依赖”来添加到你的项目中。
|
||||
|
||||
|
|
|
|||
|
|
@ -745,7 +745,7 @@ $extra = $event->getComposer()->getPackage()->getExtra();
|
|||
<a name="bin"></a>
|
||||
### bin
|
||||
|
||||
该属性用于标注一组应被视为二进制脚本的文件，他们会被软链接到（config 对象中的）`bin-dir` 属性所标注的目录，以供其他依赖库调用。
|
||||
该属性用于标注一组应被视为二进制脚本的文件，他们会被软链接到（config 对象中的）`bin-dir` 属性所标注的目录，以供其他依赖包调用。
|
||||
|
||||
详细请查看 [Vendor Binaries](articles/vendor-binaries.md)。
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@
|
|||
|
||||
分支别名是非常适合用于主开发分支的。但为了使用它们，你需要拥有对源码的控制权，并且你需要提交别名修改到你控制的版本库。
|
||||
|
||||
当你只想在本地项目中尝试一些依赖库的 bug 修正时，这并不是最好的方式。
|
||||
当你只想在本地项目中尝试一些依赖包的 bug 修正时，这并不是最好的方式。
|
||||
|
||||
出于这个原因，你可以在 `require` 和 `require-dev` 字段中直接别名你需要的包。比方说那你找到了 `monolog/monolog` 的一个 bug。你在 GitHub 上克隆了 [Monolog](https://github.com/Seldaek/monolog) 并在名为 `bugfix` 的分支上修正了一个问题。现在你想安装这个版本到你的本地项目。
|
||||
|
||||
|
|
|
|||
|
|
@ -34,23 +34,16 @@
|
|||
否则它们将会被隐藏在 `vendor/` 目录的深处。
|
||||
|
||||
|
||||
## 当 Composer 运行于定义了二进制供应库的 composer.json 时发生了什么？
|
||||
## 当 Composer 运行到定义了二进制供应库的 composer.json 文件时发生了什么？
|
||||
|
||||
For the binaries that a package defines directly, nothing happens.
|
||||
|
||||
对于被某个包直接定义的二进制库，什么也不会发生。
|
||||
对于被某个资源包直接定义的二进制供应库，什么也不会发生。
|
||||
|
||||
|
||||
## 当 Composer 运行于标明依赖于某二进制供应库的 composer.json 时发生了什么？
|
||||
## 当 Composer 运行到，列出了二进制供应库依赖关系的 composer.json 文件时发生了什么？
|
||||
|
||||
Composer looks for the binaries defined in all of the dependencies. A
|
||||
symlink is created from each dependency's binaries to `vendor/bin`.
|
||||
|
||||
Composer会检查所有依赖库里定义的二进制文件。
|
||||
Composer 会检查所有依赖包里定义的二进制文件。
|
||||
并为每一个依赖的二进制库设立一个指向 `vendor/bin` 的软连接。
|
||||
|
||||
Say package `my-vendor/project-a` has binaries setup like this:
|
||||
|
||||
比如 `my-vendor/project-a` 资源包的二进制库就是这样安装的：
|
||||
|
||||
```json
|
||||
|
|
@ -60,16 +53,10 @@ Say package `my-vendor/project-a` has binaries setup like this:
|
|||
}
|
||||
```
|
||||
|
||||
Running `composer install` for this `composer.json` will not do
|
||||
anything with `bin/project-a-bin`.
|
||||
|
||||
在该 `composer.json` 上执行 `composer install` 命令，
|
||||
不会对 `bin/project-a-bin` 造成任何影响。
|
||||
|
||||
Say project `my-vendor/project-b` has requirements setup like this:
|
||||
|
||||
但是如果 `my-vendor/project-b` 项目定义有这样的需求：
|
||||
|
||||
再比如项目 `my-vendor/project-b` 有这样的需求定义：
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -84,7 +71,7 @@ Running `composer install` for this `composer.json` will look at
|
|||
all of project-b's dependencies and install them to `vendor/bin`.
|
||||
|
||||
在该 `composer.json` 上执行 `composer install` 命令时，
|
||||
会检查 project-b 的所有依赖，并把它们中的二进制库安装到 `vendor/bin`。
|
||||
将会检查 project-b 的所有依赖包，并把它们中定义的二进制库安装到 `vendor/bin`。
|
||||
|
||||
In this case, Composer will make `vendor/my-vendor/project-a/bin/project-a-bin`
|
||||
available as `vendor/bin/project-a-bin`. On a Unix-like platform
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
一般情况下 **不建议**。vendor 目录（或者你安装依赖的其它目录）都应该被添加进 `.gitignore`/`svn:ignore`/等等。
|
||||
|
||||
最好这么做，然后让所有开发人员使用 Composer 来安装依赖关系。同样，build server、CI、deployment tools 等等，应进行修改，使运行 Composer 成为其项目引导的一部分。
|
||||
最好这么做，然后让所有开发人员使用 Composer 来安装依赖包。同样，build server、CI、deployment tools 等等，应进行修改，使运行 Composer 成为其项目引导的一部分。
|
||||
|
||||
虽然在某些环境下提交它是很让人心动的，但它将导致一些问题：
|
||||
|
||||
|
|
|
|||
|
|
@ -10,4 +10,4 @@
|
|||
|
||||
- 读取根包的存储库，同时从定义的 repos 初始化资源包，递归的初始化，根据所有依赖包中定义的 repos，以及这些依赖包所依赖的其它包中定义的 repos，等等，然后再解析依赖需求。这可能可以工作，但会严重影响初始化的速度，因为每读取一个 VCS repos 都需要几秒钟。它可能最终执行失败，因为一个包的不同版本，可能来自一个包资源库中一个相同的包，但来至不同的 dist/source 。这样有太多的可能会出错。
|
||||
|
||||
- 读取根包的存储库，然后读取第一级依赖，接着读取这些依赖包所依赖的其它包，等等，然后再解析依赖需求。这样听起来更有效率，但仍然存在第二种解决方案中的问题。因为加载依赖的储存库并不像听起来那么容易。你需要加载所有可能匹配依赖关系的 repos，而这些包的定义又可能是互相冲突的。
|
||||
- 读取根包的存储库，然后读取第一级依赖，接着读取这些依赖包所依赖的其它包，等等，然后再解析依赖需求。这样听起来更有效率，但仍然存在第二种解决方案中的问题。因为加载依赖的储存库并不像听起来那么容易。你需要加载所有可能匹配的依赖包的 repos，而这些包的定义又可能是互相冲突的。
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
# D
|
||||
|
||||
## dependencies 依赖包、依赖关系
|
||||
|
||||
# P
|
||||
|
||||
## Package 资源包
|
||||
|
|
|
|||
Loading…
Reference in New Issue