Merge pull request #9326 from naderman/docs-remove-simple-easy
Docs: Remove unnecessary uses of simple/easypull/9347/head
commit
8883c1eb15
|
@ -37,7 +37,7 @@ Composer requires PHP 5.3.2+ to run. A few sensitive php settings and compile
|
|||
flags are also required, but when using the installer you will be warned about
|
||||
any incompatibilities.
|
||||
|
||||
To install packages from sources instead of simple zip archives, you will need
|
||||
To install packages from sources instead of plain zip archives, you will need
|
||||
git, svn, fossil or hg depending on how the package is version-controlled.
|
||||
|
||||
Composer is multi-platform and we strive to make it run equally well on Windows,
|
||||
|
@ -161,6 +161,6 @@ Composer version 1.0.0 2016-01-10 20:34:53
|
|||
## Using Composer
|
||||
|
||||
Now that you've installed Composer, you are ready to use it! Head on over to the
|
||||
next chapter for a short and simple demonstration.
|
||||
next chapter for a short demonstration.
|
||||
|
||||
[Basic usage](01-basic-usage.md) →
|
||||
|
|
|
@ -18,7 +18,7 @@ other metadata as well.
|
|||
### The `require` key
|
||||
|
||||
The first (and often only) thing you specify in `composer.json` is the
|
||||
[`require`](04-schema.md#require) key. You are simply telling Composer which
|
||||
[`require`](04-schema.md#require) key. You are telling Composer which
|
||||
packages your project depends on.
|
||||
|
||||
```json
|
||||
|
@ -98,7 +98,7 @@ When you run this command, one of two things may happen:
|
|||
### Installing without `composer.lock`
|
||||
|
||||
If you have never run the command before and there is also no `composer.lock` file present,
|
||||
Composer simply resolves all dependencies listed in your `composer.json` file and downloads
|
||||
Composer resolves all dependencies listed in your `composer.json` file and downloads
|
||||
the latest version of their files into the `vendor` directory in your project. (The `vendor`
|
||||
directory is the conventional location for all third-party code in a project). In our
|
||||
example from above, you would end up with the Monolog source files in
|
||||
|
@ -211,7 +211,7 @@ available platform packages.
|
|||
## Autoloading
|
||||
|
||||
For libraries that specify autoload information, Composer generates a
|
||||
`vendor/autoload.php` file. You can simply include this file and start
|
||||
`vendor/autoload.php` file. You can include this file and start
|
||||
using the classes that those libraries provide without any extra work:
|
||||
|
||||
```php
|
||||
|
|
|
@ -142,9 +142,9 @@ Packagist is available automatically through Composer. Since
|
|||
can depend on it without having to specify any additional repositories.
|
||||
|
||||
If we wanted to share `hello-world` with the world, we would publish it on
|
||||
Packagist as well. Doing so is really easy.
|
||||
Packagist as well.
|
||||
|
||||
You simply visit [Packagist](https://packagist.org) and hit the "Submit"
|
||||
You visit [Packagist](https://packagist.org) and hit the "Submit"
|
||||
button. This will prompt you to sign up if you haven't already, and then
|
||||
allows you to submit the URL to your VCS repository, at which point Packagist
|
||||
will start crawling it. Once it is done, your package will be available to
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
You've already learned how to use the command-line interface to do some
|
||||
things. This chapter documents all the available commands.
|
||||
|
||||
To get help from the command-line, simply call `composer` or `composer list`
|
||||
To get help from the command-line, call `composer` or `composer list`
|
||||
to see the complete list of commands, then `--help` combined with any of those
|
||||
can give you more information.
|
||||
|
||||
|
@ -39,8 +39,7 @@ The following options are available with every command:
|
|||
## init
|
||||
|
||||
In the [Libraries](02-libraries.md) chapter we looked at how to create a
|
||||
`composer.json` by hand. There is also an `init` command available that makes
|
||||
it a bit easier to do this.
|
||||
`composer.json` by hand. There is also an `init` command available to do this.
|
||||
|
||||
When you run the command it will interactively ask you to fill in the fields,
|
||||
while using some smart defaults.
|
||||
|
@ -297,8 +296,8 @@ php composer.phar global update
|
|||
## search
|
||||
|
||||
The search command allows you to search through the current project's package
|
||||
repositories. Usually this will be packagist. You simply pass it the
|
||||
terms you want to search for.
|
||||
repositories. Usually this will be packagist. You pass it the terms you want
|
||||
to search for.
|
||||
|
||||
```sh
|
||||
php composer.phar search monolog
|
||||
|
@ -540,7 +539,7 @@ command. It will replace your `composer.phar` with the latest version.
|
|||
php composer.phar self-update
|
||||
```
|
||||
|
||||
If you would like to instead update to a specific release simply specify it:
|
||||
If you would like to instead update to a specific release specify it:
|
||||
|
||||
```sh
|
||||
php composer.phar self-update 1.0.0-alpha7
|
||||
|
@ -915,7 +914,7 @@ directory other than `vendor`.
|
|||
### http_proxy or HTTP_PROXY
|
||||
|
||||
If you are using Composer from behind an HTTP proxy, you can use the standard
|
||||
`http_proxy` or `HTTP_PROXY` env vars. Simply set it to the URL of your proxy.
|
||||
`http_proxy` or `HTTP_PROXY` env vars. Set it to the URL of your proxy.
|
||||
Many operating systems already set this variable for you.
|
||||
|
||||
Using `http_proxy` (lowercased) or even defining both might be preferable since
|
||||
|
@ -947,7 +946,7 @@ If set, makes the self-update command write the new Composer phar file into that
|
|||
### no_proxy or NO_PROXY
|
||||
|
||||
If you are behind a proxy and would like to disable it for certain domains, you
|
||||
can use the `no_proxy` or `NO_PROXY` env var. Simply set it to a comma separated list of
|
||||
can use the `no_proxy` or `NO_PROXY` env var. Set it to a comma separated list of
|
||||
domains the proxy should *not* be used for.
|
||||
|
||||
The env var accepts domains, IP addresses, and IP address blocks in CIDR
|
||||
|
|
|
@ -88,7 +88,7 @@ installer capable of installing packages of that type.
|
|||
|
||||
Out of the box, Composer supports four types:
|
||||
|
||||
- **library:** This is the default. It will simply copy the files to `vendor`.
|
||||
- **library:** This is the default. It will copy the files to `vendor`.
|
||||
- **project:** This denotes a project rather than a library. For example
|
||||
application shells like the [Symfony standard edition](https://github.com/symfony/symfony-standard),
|
||||
CMSs like the [SilverStripe installer](https://github.com/silverstripe/silverstripe-installer)
|
||||
|
@ -444,7 +444,7 @@ that exact version, and not any other version, which would be incorrect.
|
|||
List of other packages that are provided by this package. This is mostly
|
||||
useful for implementations of common interfaces. A package could depend on
|
||||
some virtual `logger-implementation` package, any library that implements
|
||||
this logger interface would simply list it in `provide`.
|
||||
this logger interface would list it in `provide`.
|
||||
Using `provide` with the name of an actual package rather than a virtual one
|
||||
implies that the code of that package is also shipped, in which case `replace`
|
||||
is generally a better choice. A common convention for packages providing an
|
||||
|
@ -769,7 +769,7 @@ ignored.
|
|||
|
||||
The following repository types are supported:
|
||||
|
||||
* **composer:** A Composer repository is simply a `packages.json` file served
|
||||
* **composer:** A Composer repository is a `packages.json` file served
|
||||
via the network (HTTP, FTP, SSH), that contains a list of `composer.json`
|
||||
objects with additional `dist` and/or `source` information. The `packages.json`
|
||||
file is loaded using a PHP stream. You can set extra options on that stream
|
||||
|
|
|
@ -202,7 +202,7 @@ There are a few use cases for this. The most common one is maintaining your
|
|||
own fork of a third party library. If you are using a certain library for your
|
||||
project and you decide to change something in the library, you will want your
|
||||
project to use the patched version. If the library is on GitHub (this is the
|
||||
case most of the time), you can simply fork it there and push your changes to
|
||||
case most of the time), you can fork it there and push your changes to
|
||||
your fork. After that you update the project's `composer.json`. All you have
|
||||
to do is add your fork as a repository and update the version constraint to
|
||||
point to your custom branch. In `composer.json`, you should prefix your custom
|
||||
|
@ -582,9 +582,9 @@ information.
|
|||
### Artifact
|
||||
|
||||
There are some cases, when there is no ability to have one of the previously
|
||||
mentioned repository types online, even the VCS one. Typical example could be
|
||||
cross-organisation library exchange through built artifacts. Of course, most
|
||||
of the times they are private. To simplify maintenance, one can simply use a
|
||||
mentioned repository types online, even the VCS one. A typical example could be
|
||||
cross-organisation library exchange through build artifacts. Of course, most
|
||||
of the time these are private. To use these archives as-is, one can use a
|
||||
repository of type `artifact` with a folder containing ZIP archives of those
|
||||
private packages:
|
||||
|
||||
|
|
|
@ -279,14 +279,12 @@ scripts if you tend to have modified vendors.
|
|||
|
||||
## archive-format
|
||||
|
||||
Defaults to `tar`. Composer allows you to add a default archive format when the
|
||||
workflow needs to create a dedicated archiving format.
|
||||
Defaults to `tar`. Overrides the default format used by the archive command.
|
||||
|
||||
## archive-dir
|
||||
|
||||
Defaults to `.`. Composer allows you to add a default archive directory when the
|
||||
workflow needs to create a dedicated archiving format. Or for easier development
|
||||
between modules.
|
||||
Defaults to `.`. Default destination for archives created by the archive
|
||||
command.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@ it can immediately be discovered/used without having to rebuild the autoloader
|
|||
configuration.
|
||||
|
||||
The problem however is in production you generally want things to happen as fast
|
||||
as possible, as you can simply rebuild the configuration every time you deploy and
|
||||
as possible, as you can rebuild the configuration every time you deploy and
|
||||
new classes do not appear at random between deploys.
|
||||
|
||||
For this reason, Composer offers a few strategies to optimize the autoloader.
|
||||
|
@ -67,7 +67,7 @@ There are a few options to enable this:
|
|||
|
||||
Enabling this automatically enables Level 1 class map optimizations.
|
||||
|
||||
This option is very simple, it says that if something is not found in the classmap,
|
||||
This option says that if something is not found in the classmap,
|
||||
then it does not exist and the autoloader should not attempt to look on the
|
||||
filesystem according to PSR-4 rules.
|
||||
|
||||
|
|
|
@ -189,7 +189,7 @@ class TemplateInstaller extends LibraryInstaller
|
|||
}
|
||||
```
|
||||
|
||||
The example demonstrates that it is quite simple to extend the
|
||||
The example demonstrates that it is possible to extend the
|
||||
[`Composer\Installer\LibraryInstaller`][5] class to strip a prefix
|
||||
(`phpdocumentor/template-`) and use the remaining part to assemble a completely
|
||||
different installation path.
|
||||
|
|
|
@ -13,7 +13,7 @@ files which makes installs faster and independent from third party systems - e.g
|
|||
you can deploy even if GitHub is down because your zip files are mirrored.
|
||||
|
||||
Private Packagist is available as a hosted SaaS solution or as an on-premise self-hosted
|
||||
package, providing an easy interactive set up experience.
|
||||
package, providing an interactive set up experience.
|
||||
|
||||
Some of Private Packagist's revenue is used to pay for Composer and Packagist.org
|
||||
development and hosting so using it is a good way to support the maintenance of
|
||||
|
|
|
@ -202,7 +202,7 @@ and can be retrieved as an array via `$event->getArguments()` by PHP handlers.
|
|||
If you add custom scripts that do not fit one of the predefined event name
|
||||
above, you can either run them with run-script or also run them as native
|
||||
Composer commands. For example the handler defined below is executable by
|
||||
simply running `composer test`:
|
||||
running `composer test`:
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -218,7 +218,7 @@ to the `phpunit` script.
|
|||
|
||||
> **Note:** Before executing scripts, Composer's bin-dir is temporarily pushed
|
||||
> on top of the PATH environment variable so that binaries of dependencies
|
||||
> are easily accessible. In this example no matter if the `phpunit` binary is
|
||||
> are directly accessible. In this example no matter if the `phpunit` binary is
|
||||
> actually in `vendor/bin/phpunit` or `bin/phpunit` it will be found and executed.
|
||||
|
||||
Although Composer is not intended to manage long-running processes and other
|
||||
|
|
|
@ -18,7 +18,7 @@ In Composer, what's often referred to casually as a version -- that is,
|
|||
the string that follows the package name in a require line (e.g., `~1.1` or
|
||||
`1.2.*`) -- is actually more specifically a version constraint. Composer
|
||||
uses version constraints to figure out which refs in a VCS it should be
|
||||
checking out (or simply to verify that a given library is acceptable in
|
||||
checking out (or to verify that a given library is acceptable in
|
||||
the case of a statically-maintained library with a `version` specification
|
||||
in `composer.json`).
|
||||
|
||||
|
|
|
@ -6,7 +6,7 @@ the default `vendor` folder by using
|
|||
[composer/installers](https://github.com/composer/installers).
|
||||
|
||||
If you are a **package author** and want your package installed to a custom
|
||||
directory, simply require `composer/installers` and set the appropriate `type`.
|
||||
directory, require `composer/installers` and set the appropriate `type`.
|
||||
Specifying the package type, will override the default installer path.
|
||||
This is common if your package is intended for a specific framework such as
|
||||
CakePHP, Drupal or WordPress. Here is an example composer.json file for a
|
||||
|
|
|
@ -16,6 +16,6 @@ For example instead of using `>=3.4` you should use `~3.4` which allows all
|
|||
versions up to `3.999` but does not include `4.0` and above. The `^` operator
|
||||
works very well with libraries following [semantic versioning](https://semver.org).
|
||||
|
||||
**Note:** As a package maintainer, you can make the life of your users easier
|
||||
**Note:** As a package maintainer, you can make the help your users
|
||||
by providing an [alias version](../articles/aliases.md) for your development
|
||||
branch to allow it to match bound constraints.
|
||||
|
|
|
@ -17,5 +17,5 @@ of a package in version 3.0.0 or not. Should it match because you asked for
|
|||
`>=2` or should it not match because you asked for a `2.*`?
|
||||
|
||||
For this reason, Composer throws an error and says that this is invalid.
|
||||
The easy way to fix it is to think about what you really mean, and use only
|
||||
The way to fix it is to think about what you really mean, and use only
|
||||
one of those rules.
|
|
@ -4,7 +4,7 @@ This directory contains some examples of what `composer` type repositories can
|
|||
look like. They serve as illustrating examples accompanying the docs, but can
|
||||
also be used as (initial) fixtures for tests.
|
||||
|
||||
* `repo-composer-plain` is a simple, plain `packages.json` file
|
||||
* `repo-composer-plain` is a basic, plain `packages.json` file
|
||||
* `repo-composer-with-includes` uses the `includes` mechanism
|
||||
* `repo-composer-with-providers` uses the `providers` mechanism
|
||||
|
||||
|
|
Loading…
Reference in New Issue