public-mirrors
/
composer
mirror of https://github.com/composer/composer
1
0
Fork 0
Code

English corrections and clarifications 

Updated the PEAR `vendor-alias` documentation for clarity and proper English
pull/1220/head
Jonathon Hill 2012-10-16 15:32:07 -03:00
parent d8387ddbdd
commit 02d5d5219b
1 changed files with 26 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
doc/05-repositories.md
View File

@ -239,33 +239,40 @@ In this case the short name of the channel is `pear2`, so the
> **Note:** The `pear` repository requires doing quite a few requests per
> package, so this may considerably slow down the installation process.
#### Custom channel alias
#### Custom vendor alias
It is possible to alias all pear channel packages with custom name.
It is possible to alias PEAR channel packages with a custom vendor name.
Example:
You own private pear repository and going to use composer abilities to bring
dependencies from vcs or transit to composer repository scheme. Your
repository list of packages:
Suppose you have a private PEAR repository and wish to use Composer to
incorporate dependencies from a VCS. Your PEAR repository contains the
following packages:
* BasePackage, requires nothing
* IntermediatePackage, depends on BasePackage
* TopLevelPackage1 and TopLevelPackage2 both depend on IntermediatePackage.
* `BasePackage`
* `IntermediatePackage`, which depends on `BasePackage`
* `TopLevelPackage1` and `TopLevelPackage2` which both depend on `IntermediatePackage`
For composer it looks like:
Without a vendor alias, Composer will use the PEAR channel name as the
vendor portion of the package name:
* "pear-pear.foobar.repo/IntermediatePackage" depends on "pear-pear.foobar.repo/BasePackage",
* "pear-pear.foobar.repo/TopLevelPackage1" depends on "pear-pear.foobar.repo/IntermediatePackage",
* "pear-pear.foobar.repo/TopLevelPackage2" depends on "pear-pear.foobar.repo/IntermediatePackage"
* `pear-pear.foobar.repo/BasePackage`
* `pear-pear.foobar.repo/IntermediatePackage`
* `pear-pear.foobar.repo/TopLevelPackage1`
* `pear-pear.foobar.repo/TopLevelPackage2`
When you update one of your packages to composer naming scheme or made it
available through vcs, your older dependencies would not see new version,
cause it would be named like "foobar/IntermediatePackage". Specifying 'vendor-
alias' for pear repository, you will get all its packages aliased with
composer-like names. Following example would take BasePackage,
TopLevelPackage1 and TopLevelPackage2 packages from pear repository and
IntermediatePackage from github repository:
Suppose at a later time you wish to migrate your PEAR packages to a
Composer repository and naming scheme, and adopt the vendor name of `foobar`.
Projects using your PEAR packages would not see the updated packages, since
they have a different vendor name (`foobar/IntermediatePackage` vs
`pear-pear.foobar.repo/IntermediatePackage`).
By specifying `vendor-alias` for the PEAR repository from the start, you can
avoid this scenario and future-proof your package names.
To illustrate, the following example would get the `BasePackage`,
`TopLevelPackage1`, and `TopLevelPackage2` packages from your PEAR repository
and `IntermediatePackage` from a Github repository:
{
"repositories": [