From 454ddc3b24fabb2013b93ebc05fc21c96b9dbab7 Mon Sep 17 00:00:00 2001 From: bcw Date: Sun, 22 Jun 2014 19:30:14 +0800 Subject: [PATCH] update --- cn-introduction/01-basic-usage.md | 4 +-- cn-introduction/02-libraries.md | 2 +- cn-introduction/04-schema.md | 2 +- cn-introduction/articles/aliases.md | 2 +- cn-introduction/articles/vendor-binaries.md | 25 +++++-------------- ...the-dependencies-in-my-vendor-directory.md | 2 +- ...-composer-load-repositories-recursively.md | 2 +- glossary.md | 4 +++ 8 files changed, 17 insertions(+), 26 deletions(-) diff --git a/cn-introduction/01-basic-usage.md b/cn-introduction/01-basic-usage.md index 2a9c054..93ef681 100644 --- a/cn-introduction/01-basic-usage.md +++ b/cn-introduction/01-basic-usage.md @@ -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) 设置，而不是每个依赖逐一设置。 -## 安装依赖关系 +## 安装依赖包 获取定义的依赖到你的本地项目，只需要调用 `composer.phar` 运行 `install` 命令。 diff --git a/cn-introduction/02-libraries.md b/cn-introduction/02-libraries.md index ec9f1ca..e716db4 100644 --- a/cn-introduction/02-libraries.md +++ b/cn-introduction/02-libraries.md @@ -156,7 +156,7 @@ hg) 的信息推断出包的版本，因此你不必手动指明版本号，并 更多关于包的来源是如何工作的，以及还有什么其他的类型可供选择，请查看[资源库](05-repositories.md)。 -这就是全部了。你现在可以使用 Composer 的 `install` 命令来安装你的依赖关系了！ +这就是全部了。你现在可以使用 Composer 的 `install` 命令来安装你的依赖包了！ **小结：** 任何含有 `composer.json` 的 `GIT`、`SVN`、`HG` 存储库，都可以通过 `require` 字段指定“包来源”和“声明依赖”来添加到你的项目中。 diff --git a/cn-introduction/04-schema.md b/cn-introduction/04-schema.md index deaa642..bedc4e5 100644 --- a/cn-introduction/04-schema.md +++ b/cn-introduction/04-schema.md @@ -745,7 +745,7 @@ $extra = $event->getComposer()->getPackage()->getExtra(); ### bin -该属性用于标注一组应被视为二进制脚本的文件，他们会被软链接到（config 对象中的）`bin-dir` 属性所标注的目录，以供其他依赖库调用。 +该属性用于标注一组应被视为二进制脚本的文件，他们会被软链接到（config 对象中的）`bin-dir` 属性所标注的目录，以供其他依赖包调用。 详细请查看 [Vendor Binaries](articles/vendor-binaries.md)。 diff --git a/cn-introduction/articles/aliases.md b/cn-introduction/articles/aliases.md index 493f643..2f68414 100644 --- a/cn-introduction/articles/aliases.md +++ b/cn-introduction/articles/aliases.md @@ -38,7 +38,7 @@ 分支别名是非常适合用于主开发分支的。但为了使用它们，你需要拥有对源码的控制权，并且你需要提交别名修改到你控制的版本库。 -当你只想在本地项目中尝试一些依赖库的 bug 修正时，这并不是最好的方式。 +当你只想在本地项目中尝试一些依赖包的 bug 修正时，这并不是最好的方式。 出于这个原因，你可以在 `require` 和 `require-dev` 字段中直接别名你需要的包。比方说那你找到了 `monolog/monolog` 的一个 bug。你在 GitHub 上克隆了 [Monolog](https://github.com/Seldaek/monolog) 并在名为 `bugfix` 的分支上修正了一个问题。现在你想安装这个版本到你的本地项目。 diff --git a/cn-introduction/articles/vendor-binaries.md b/cn-introduction/articles/vendor-binaries.md index 4abfd96..ed73a46 100644 --- a/cn-introduction/articles/vendor-binaries.md +++ b/cn-introduction/articles/vendor-binaries.md @@ -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 diff --git a/cn-introduction/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md b/cn-introduction/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md index 5aca046..43534aa 100644 --- a/cn-introduction/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md +++ b/cn-introduction/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md @@ -2,7 +2,7 @@ 一般情况下 **不建议**。vendor 目录（或者你安装依赖的其它目录）都应该被添加进 `.gitignore`/`svn:ignore`/等等。 -最好这么做，然后让所有开发人员使用 Composer 来安装依赖关系。同样，build server、CI、deployment tools 等等，应进行修改，使运行 Composer 成为其项目引导的一部分。 +最好这么做，然后让所有开发人员使用 Composer 来安装依赖包。同样，build server、CI、deployment tools 等等，应进行修改，使运行 Composer 成为其项目引导的一部分。 虽然在某些环境下提交它是很让人心动的，但它将导致一些问题： diff --git a/cn-introduction/faqs/why-can't-composer-load-repositories-recursively.md b/cn-introduction/faqs/why-can't-composer-load-repositories-recursively.md index 4b95922..781e6e9 100644 --- a/cn-introduction/faqs/why-can't-composer-load-repositories-recursively.md +++ b/cn-introduction/faqs/why-can't-composer-load-repositories-recursively.md @@ -10,4 +10,4 @@ - 读取根包的存储库，同时从定义的 repos 初始化资源包，递归的初始化，根据所有依赖包中定义的 repos，以及这些依赖包所依赖的其它包中定义的 repos，等等，然后再解析依赖需求。这可能可以工作，但会严重影响初始化的速度，因为每读取一个 VCS repos 都需要几秒钟。它可能最终执行失败，因为一个包的不同版本，可能来自一个包资源库中一个相同的包，但来至不同的 dist/source 。这样有太多的可能会出错。 -- 读取根包的存储库，然后读取第一级依赖，接着读取这些依赖包所依赖的其它包，等等，然后再解析依赖需求。这样听起来更有效率，但仍然存在第二种解决方案中的问题。因为加载依赖的储存库并不像听起来那么容易。你需要加载所有可能匹配依赖关系的 repos，而这些包的定义又可能是互相冲突的。 +- 读取根包的存储库，然后读取第一级依赖，接着读取这些依赖包所依赖的其它包，等等，然后再解析依赖需求。这样听起来更有效率，但仍然存在第二种解决方案中的问题。因为加载依赖的储存库并不像听起来那么容易。你需要加载所有可能匹配的依赖包的 repos，而这些包的定义又可能是互相冲突的。 diff --git a/glossary.md b/glossary.md index 04feddb..c09498c 100644 --- a/glossary.md +++ b/glossary.md @@ -1,3 +1,7 @@ +# D + +## dependencies 依赖包、依赖关系 + # P ## Package 资源包