From d93f03d0c4ee773322ff0e416777f584a3c7fb7e Mon Sep 17 00:00:00 2001 From: Igor Wiedler Date: Wed, 29 Aug 2012 22:30:47 +0200 Subject: [PATCH] Re-wrap and re-format some docs to make the LaTeX friendly --- doc/05-repositories.md | 17 ++++++++++++++--- doc/articles/aliases.md | 1 + doc/articles/custom-installers.md | 11 ++++++----- .../handling-private-packages-with-satis.md | 1 + doc/articles/scripts.md | 1 + doc/articles/vendor-bins.md | 1 + 6 files changed, 24 insertions(+), 8 deletions(-) diff --git a/doc/05-repositories.md b/doc/05-repositories.md index 2e2672ccd..34bf111b2 100644 --- a/doc/05-repositories.md +++ b/doc/05-repositories.md @@ -229,21 +229,32 @@ In this case the short name of the channel is `pear2`, so the > package, so this may considerably slow down the installation process. #### Custom channel alias + It is possible to alias all pear channel packages with custom 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: + +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: + * BasePackage, requires nothing * IntermediatePackage, depends on BasePackage * TopLevelPackage1 and TopLevelPackage2 both dependth on IntermediatePackage. For composer it looks like: + * "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" -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: +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: { "repositories": [ diff --git a/doc/articles/aliases.md b/doc/articles/aliases.md index 38e0e65ee..9966100ea 100644 --- a/doc/articles/aliases.md +++ b/doc/articles/aliases.md @@ -1,6 +1,7 @@ + # Aliases ## Why aliases? diff --git a/doc/articles/custom-installers.md b/doc/articles/custom-installers.md index 1f3d68f10..3ac4eeb6a 100644 --- a/doc/articles/custom-installers.md +++ b/doc/articles/custom-installers.md @@ -1,6 +1,7 @@ + # Setting up and using custom installers ## Synopsis @@ -48,15 +49,15 @@ An example composer.json of such a template package would be: ## Creating an Installer A Custom Installer is defined as a class that implements the -[\Composer\Installer\InstallerInterface][3] and is contained in a Composer +[`Composer\Installer\InstallerInterface`][3] and is contained in a Composer package that has the [type][1] `composer-installer`. A basic Installer would thus compose of two files: 1. the package file: composer.json -2. The Installer class, i.e.: \Composer\Installer\MyInstaller.php +2. The Installer class, i.e.: `Composer\Installer\MyInstaller.php` -> **NOTE**: _The namespace does not need to be \Composer\Installer, it must +> **NOTE**: _The namespace does not need to be `Composer\Installer`, it must > only implement the right interface._ ### composer.json @@ -86,7 +87,7 @@ Example: ### The Custom Installer class The class that executes the custom installation should implement the -[\Composer\Installer\InstallerInterface][3] (or extend another installer that +[`Composer\Installer\InstallerInterface`][3] (or extend another installer that implements that interface). The class may be placed in any location and have any name, as long as it is @@ -148,7 +149,7 @@ Example: } The example demonstrates that it is quite simple to extend the -[\Composer\Installer\LibraryInstaller][4] class to strip a prefix +[`Composer\Installer\LibraryInstaller`][4] class to strip a prefix (`phpdocumentor/template-`) and use the remaining part to assemble a completely different installation path. diff --git a/doc/articles/handling-private-packages-with-satis.md b/doc/articles/handling-private-packages-with-satis.md index d615e0178..722a497ad 100644 --- a/doc/articles/handling-private-packages-with-satis.md +++ b/doc/articles/handling-private-packages-with-satis.md @@ -1,6 +1,7 @@ + # Handling private packages with Satis Satis can be used to host the metadata of your company's private packages, or diff --git a/doc/articles/scripts.md b/doc/articles/scripts.md index 3da238f31..3efaccc32 100644 --- a/doc/articles/scripts.md +++ b/doc/articles/scripts.md @@ -1,6 +1,7 @@ + # Scripts ## What is a script? diff --git a/doc/articles/vendor-bins.md b/doc/articles/vendor-bins.md index a915bbca6..d9b87214d 100644 --- a/doc/articles/vendor-bins.md +++ b/doc/articles/vendor-bins.md @@ -1,6 +1,7 @@ + # bin and vendor/bin ## What is a bin?